variable name length exceeds 63 characters

Hello, I'm new here:) maybe you can help me with a problem. I need to use some variables whose names are exceeding 63 characters. Does anyone have any idea? I must fix this problem quickly:D

Thanks in advance!

[Nathan Greco]

As always, examples help. What do your variable names look like?

Answer 1

[Jan]

Your demand for more than 63 characters sounds, like you store important values in the name instead of the contents of a variable. A program using such long symbols is nearly unreadable and debugging will be ridiculous hard.

Beside the fact, that the limit of 63 characters is hard coded and cannot be changed in MATLAB, I assume that there is a misconcept in your program design. Please explain, why you want to stuff so much information in the names.

[Oleg Komarov]

Agree with Jan, exactly my point as well.

[Jan]

@Oleg: I agree with you. While you focussed on the practical view, I tried to convince Diana by theory to avoid such worms.

[Paulo Silva]

if ThisVariableHoldsJansMATLABAnswersReputation>=1500

disp('Congratulations!!!')

else

disp('Almost there, good work!')

end

%I agree with Jan and Oleg, use small variable names and abuse the comments

[Jan]

You mean: if ThisVariableHoldsJansMATLABAnswersReputation_on_the_26th_of_Juli_2011_13_35_15_UTC ?!

[Paulo Silva]

No Jan, that's another variable, my comment was for any time someone read the comment not just that day :) btw keep up the good work.

[BenRaanan]

Hi Jan,

"Beside the fact, that the limit of 63 characters is hard coded and cannot be changed in MATLAB"... Sounds to me like perhaps there is a misconception in MathWorks program design.

Anyway, I agree that programmers should generally avoid using long variable names when unnecessary, but why limit users in such a way? For example, scientists working with CF Standard Names ( http://cfconventions.org ) have to come up with workarounds for this kind of stuff.

It would be great if users could configure the char limit.

[Walter Roberson]

Misconception?? I would not say so. Real programming involves a lot of tradeoffs.

The matlab internal symbol table for functions involves several pools, each holding different scopes of variables. Each of the pools involves fixed length entries, including the literal symbol, probably in uncounted null padded form. Each pool consists several blocks allocated from a fixed size block memory allocator. Adding a new variable involves finding an unused slot and writing a fixed length entry into it. It would not surprise me if the flag indicating whether the slot is used, is whether the first byte of the name field is null.

Returning from the function involves walking pools, checking if the slot is used, and passing the mxarray pointer to the routine that decrements the reference count and returns the memory for the mxarray upon reaching 0, potentially triggering destructors along the way. Once the pool is walked the fixed length blocks are returned to the small block pool that matlab keeps. MATLAB never fragments those blocks, only hands out full blocks, so allocation routines can be efficient. Because the symbol names are part of the fixed length entries (that is, a struct array), there is no need to do memory management on the symbol names, as would be required if the symbol names were a pointer to a C++ string object.

In this scheme, the only memory allocation in the symbol table is the case where the existing fixed length blocks are full and it is time to allocate a new one out of the fixed length blocks pool.

If the user were permitted to control the maximum variable name length then a significant amount of memory management would be required just for handling the symbol names, and comparing names would require a string comparison function call instead of just comparing a fixed memory block (64 bytes)

[Patrick Stetz]

I'm not in control of the full data workflow so I'm given a CSV to run my processing scripts on. Roughly, I'm getting correlations of columns between multiple tables. I link the correlation value with the column name and it seems some column names I'm given are more than 63 characters

I'm surprised the accepted answer is that the "user" or "case" is wrong without giving a workaround. My suggested workaround to anyone is to migrate some parts of code to python

[Rik]

The workaround is to not store data in a variable name. I have not yet seen a case where there was a legitimate need for variables over 63 characters. Can you provide more details? I'm here to learn, so your use case might be the first I see.

[Walter Roberson]

https://www.mathworks.com/help/matlab/ref/genvarname.html

or the newer https://www.mathworks.com/help/matlab/ref/matlab.lang.makeuniquestrings.html

[Stefan]

I have the same problem reading JSON files with variable names longer than 63. The key names are fixed and cannot be changed. Even Python can handle this. Shame on Matlab. Matlab costs a lot of money and i still have to write work arounds for their bugs.

[Walter Roberson]

@Stefan

What would have been the "correct" limit for variable length?

[Steven Lord]

Just FYI, there's an entry in the Release Notes for release R2024a that may be of interest:

"The maximum length of MATLAB identifiers will increase in a future release. This change allows variables, functions, classes, and many other entities to have names that exceed 63 characters. Code that depends on identifiers having a maximum length of 63 characters may no longer run as expected."

Code that has hard-coded the 63 character limit should be using the namelengthmax function instead.

[Rik]

A further note: I ran into a bug once where a field name of a struct was not valid. The mex interface had no trouble handing back a struct with this field name, but a lot of indexing operations into the struct were broken.

You could make use of this fact and design a JSON parser in C and mex-compile it.

For my use case, this was a bug. I did not check in which releases this behavior exists. It might actually have been a bug and be removed by now.

Answer 2

[AL REY]

Hello, I might reopen this topic. But i would like to add a reason why we do have so long name. On my side i'm using '.mf4' data from CANAPE (Vector), the recorded label are often the software structure and exceed the 63 limit, it's also something that we can change unless we change the software dictionary. Some native matlab function (blockset) as mdf('name.mf4') and read can't deal with such naming.

It will be nice to have a way to avoid that limit.

[Walter Roberson]

Make the recorded label data rather than a variable name at the MATLAB level.

Answer 3

[James Marriott]

Sorry to re-open this question again, but I too have a need for >63 characters but in Simulink, who seems to inherit the 63 character limit chosen by MathWorks.

The reason for this need is that Autosar has started allowing 128 characters for variable names and the MISRA C 2004 rule 5.1 has been superseded by MISRA C 2012 “different external identifiers be distinct within the limits imposed by the implementation” (emphasis mine)

This means now interface signals in autosar are being meaningfully named with use of 128 characters, but then in Simulink we are having to try and contain the same meaning in only 63 characters, this is leading to a significant loss of readability and traceability within the models.

This is made even worse by having enumerations having the same restrictions. I agree that variable names >63 can hinder readability of code, but enumerations often are required to convey a greater meaning within them, so require >63 characters.

I really hope in a future release this limitation is removed, as it is making integration with our lower-level software a real challenge, and some teams are moving away from the toolset, whilst a agree it may not be desirable to use such long variable names, it should be up to the developer to decide, not MathWorks.

[Rik]

Are you advocating for abolishing the limit altogether? Or do you want to move it to 128?

[Walter Roberson]

By the way, the limit for Microsoft's C compiler is 247 characters

https://learn.microsoft.com/en-us/cpp/c-language/c-identifiers?view=msvc-170

The limit for Microsoft's C++ compiler is 2048 characters

https://learn.microsoft.com/en-us/cpp/cpp/identifiers-cpp?view=msvc-170

For gcc (and so mingw) then https://gcc.gnu.org/onlinedocs/gcc/Identifiers-implementation.html

For internal names, all characters are significant. For external names, the number of significant characters are defined by the linker; for almost all targets, all characters are significant.

Therefore if the goal is to be consistent with MISRA C 2012 "within the limits imposed by the implementation" then the limit when using MS C is 247, for MS C++ is 2048, and for gcc and mingw should be unlimited

It follows, then, that @James Marriott is requesting that the limit be abolished altogether. since some users might be using gcc / mingw for which MISRA C 2012 permits up to the implementation limit.

[Stephen]

Hi. We have a database app from which users can make various selections, based on which the app will build a mat file. The file may contain hundreds of structs each containing multiple parameters (essentially, the app builds extracts from a database). The struct names are made of several small, underscore-separated identifiers that tell the user where the data came from (e.g., test-type_lab_section_group_date_sample). A user could have some struct names that differ in only one identifier, so we hope to be able to allow users to see each full struct name to distinguish between them, without having to open the structs. We exceed the 63-character limit on thousands of structs. For us, it would help if you could increase the allowed name length. In our case, the longest name is 69 characters, though we cut all names down by 7 characters to get there. Thank you.

[Rik]

Is the variable name the best way to do this? This sounds to me like you are storing data in variable names. You might want to consider creating a system that scales beyond a few dozen characters, since this setup will reach the limits of practicality, even if MathWorks decides to change the limit in version 10.

[Stephen23]

"The struct names are made of several small, underscore-separated identifiers that tell the user where the data came from (e.g., test-type_lab_section_group_date_sample"

Meta-data is data. Data should be stored in variables, not in variable names:

https://www.mathworks.com/matlabcentral/answers/56124-eval-is-evil-using-variables-created-dynamically-info-retrieval#answer_67978

https://www.mathworks.com/matlabcentral/answers/225435-save-variable-as-string-from-user-input#answer_184104

Your current approach is a dead-end: it forces you into writing slow, complex, fragile, inefficient code to generate/parse those awkward, fragile, looooong variable names. Best avoided.

"we hope to be able to allow users to see each full struct name to distinguish between them, without having to open the structs"

Better data design would store all of that meta-data in those structures (note that you can add any number of fields you want to a structure, and that you can store the (meta-)data in its native class/type rather than awkwardly force everything into text). If the intent is to lets your users compare/select (meta-)data, then MATLAB offers much better approaches (better than forcing your users to read and compare lots of loooooong variable names): e.g. GUIs, the variable viewer, etc. for which a table or similar might be a useful data type.

Hopefully you do not have lots of those variables imported into the workspace.

Answer 4

[Oleg Komarov]

Cannot help, but why do you need such long names?

Names are meant to identify quickly a variable, if you're trying to include meta data in the name I would rather suggest to create a structure with meta fields and data field.

s.description = 'longdescription'
s.place = 'myPlace'
s.data = 10;

EDIT

To search for files keep a cell array with short names (the ones you actually save the file as) and the long ones:

names = {'ak47_19992102', 'long description'
         'ak47_19992102', 'another long description'};

search on the second column and match with teh real names.

Or using the struct array you can search through all the s.description

Also, are you using/planning to use eval?

[Diana Acreala]

Variable name must be explicit, among others should include the name of a graph axis and exceeds 63 characters (to do a search when needed).. it's a must to do this and I can't find any solution..

Thanks for you answer :)

[Oleg Komarov]

Se the edit in my answer.

Answer 5

[Walter Roberson]

This is not possible in MATLAB.

Perhaps it would make more sense to break your variable up in to a structure. For example, instead of

one_two_three_four_five

you could use

one.two.three.four.five

which would be a structure array.

Answer 6

[Walter Roberson]

Possibly the Map Container would be suitable for your work, allowing you to index variables according to arbitrary strings. See here

Answer 7

[Diana Acreala]

OK! Thank you all for your answers!

I will change my idea of solving the problem, I decided to reorganize the GUI and it is not necessary to create a structure. However, is a good idea for the future. Now I have many variables and the client does not know yet how he wants the variables to be organized.

Now I'm stuck on something else, but I will write a message with a new topic:D

Success!!

[Clarisse]

Hi,

I ended up on this post after looking for my matlab warning of "exceeds the MATLAB maximum name length of 63". The thing is I dont need the variable to have such a long name, I am trying to use GetEchoString, so that's why my responses will be longer?

Any help greatly appreciated!

Thanks!

[Steven Lord]

You're using GetEchoString and attempting to use the output to create a variable by that name using eval? Dynamically creating variable names is somewhat discouraged around here and IMO for good reason. Tell us a little more about what you're trying to do with the output from GetEchoString and we may be able to suggest alternatives.

[Jan]

@Clarisse: Please post the relevant part of your code, such that we can reconsider, what you are trying to do.

[Walter Roberson]

... and posting as a new Question would be a good idea.

Answer 8

[Stéphane]

Hello,

I reopen the topic: on my side also I need variable names longer than 63 characters.

Yes these long names are providing a lot of information describing the variable and are especially useful to name the variables in the interface of a generated code (from a model for example). Of course this information could also be stored in a metadata structure, but If the code is then used by a caller not able to handle this metadata, this information will be lost (or at least not visible at the caller's level). The most secure and portable way to link a metadata to it's variable is to put this data in the name of the variable.

I'm nevertheless not that much intererested in debating if it is a good practice or not to use long variable names. One can have this need and it's really unfortunate that Matlab limits the variable names to such a low value. Is there a real technical reason behind ? I hope that a way could be found in the future to get rid of this limitation.

[Walter Roberson]

I described a real technical reason in https://www.mathworks.com/matlabcentral/answers/12350-variable-name-length-exceeds-63-characters#comment_722675

[Walter Roberson]

Your argument for the reason to support long variables does not have any natural limit on variable name lengths. You find 63 to be too small, but since you are using generated code that might have a number of different semantic layers to each variable, clearly 255 might be too small for your purposes as well. How about 65535? You could be doing generated code operating on generated code, so better not limit it to 65535 either.

It follows that your only hard limit should be the maximum array size supported on the hardware MATLAB runs on, same as the maximum array size supported by MATLAB, 2^48-1 bytes. The Intel x64 hardware in theory has 64 bit address paths, but in practice the chips for all publicly known versions are only designed with 48 address lines.

So, you have your 7 terrabyte variable name in one function, and by your arguments about callers, you expect other functions to be accessing the same variable name (you do not expect the names to be local to a single function.) It would obviously be inefficient to store the name twice in MATLAB. This suggests that instead of storing variable names in fixed-length structures, that MATLAB should instead be allocating character vectors for each of them and the symbol tables should point to the character vector -- and that this all should be a global table with reference counters, and some way (hash tables?) to quickly locate individual variables.

Since this is all for the convenience of generated code, it follows that at the same time, MATLAB should remove or alleviate the restriction on which characters are permitted in variable names, permitting at the very least the "alphabetic" letters in multiple languages, and permitting diacretic marks.

Should all be easy, right? No "real" technical reason against doing it, right?

Based on MISRA C 2004:

Rule 5.1 (required): Identifiers (internal and external) shall not rely on the

significance of more than 31 characters. [Undefined 7; Implementation 5, 6] The

ISO standard requires internal identifiers to be distinct in the first 31 characters

to guarantee code portability. This limitation shall not be exceeded, even if the

compiler supports it. This rule shall apply across all name spaces. Macro names

are also included and the 31 character limit applies before and after substitution.

The ISO standard requires external identifiers to be distinct in the first 6

characters, regardless of case, to guarantee optimal portability. However this

limitation is particularly severe and is considered unnecessary. The intent of this

rule is to sanction a relaxation of the ISO requirement to a degree commensurate with

modern environments and it shall be confirmed that 31 character/ case significance

is supported by the implementation. Note that there is a related issue with using

identifier names that differ by only one or a few characters, especially if the

identifier names are long. The problem is heightened if the differences are in

easily mis-read characters like 1 (one) and l (lower case L), 0 and O, 2 and Z,

5 and S, or n and h. It is recommended to ensure that identifier names are always

easily visually distinguishable. Specific guidelines on this issue could be placed

in the style guidelines (see section 4.2.2).