Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

738
Views
Why the size of the const char *arr is greater then const char arr[]?

enter image description hereI am using the xc32 compiler for the microchip pic32 microcontroller.

The program memory size (for the startup, vectors and etc..) is 1656 bytes.

#include <plib.h>
#include <stdio.h>
#include <stdint.h>
#include <stdarg.h>
#include <string.h>

//if I use const char array[] for string literal then the size of the program memory increased 
//equal to the string length(only 12 bytes)

//const char array[] = "Hello World"; //program mem size(1668 0x684) bytes

//but in this case size increased 28 bytes
//const char *array = "Hello World";  //program mem size(1684 0x694) bytes



int main {

    while(1);
}

for optimization purposes:

which one is good(for both speed and size)?

  1. #define STRLIT "HELLO WORLD"
  2. const char *strlit = "HELLO WORLD";
  3. const char arr[] = "HELLO WORLD"
over 4 years ago · Santiago Trujillo
2 answers
Answer question

0

Generally, memory on a MCU is stored like this: What resides in the different memory types of a microcontroller? This means:

  • The string literal "HELLO WORLD" itself is very likely stored in a .rodata flash ROM section.

  • When you do const char array[] = "Hello World"; at file scope, the array variable should be allocated in .rodata. So there is no need to allocate the string literal or that would mean redundant allocation.

  • When you do const char *array then you declare a pointer and it it is not allocated in flash, but in the .data section of RAM. So this will mean RAM and flash consumption both. Please note that this pointer is read/write - you can assign it somewhere else but you can't change the pointed-at contents.

    To allocate the pointer in flash ROM, you need to do const char* const array.

As for why you get "28 bytes" of something, I don't know. I haven't used this part but a brief research here claims that it might have Von Neumann characteristics, from the C programmers point of view, even though the core is Harvard. Not sure what that boils down to, but this matters since Harvard architectures might need to execute some support overhead code to access flash ROM data, which in turn leads to slightly larger executable size. You need to disassemble if you want to know the specifics.

over 4 years ago · Santiago Trujillo Report

0

There are differences between your 3 options:

  • #define STRLIT "HELLO WORLD" defines a preprocessor token: no code or data is generated in the executable, yet every instance of STRLIT in the code will be replaced with the string literal at compile time, which may generate more data or not.
  • const char arr[] = "HELLO WORLD" defines a named array of char of size 12 bytes, initialized and null terminated. It takes 12 bytes in the executable read-only data segment, which may increase the size of the executable by 12 bytes or more depending on alignment constraints in the executable format.
  • const char *strlit = "HELLO WORLD"; defined both a string literal (a constant array of size 12 bytes) and a modifiable pointer strlit initialized to point to the string literal. This should at least use 4 bytes more in the executable (the size of a pointer on your 32-bit target system), but may increase the size of the executable by more than 4 bytes again depending on alignment constraints in the executable format.

Note also that depending on compiler options, there might be debugging data present in the executable file.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!