# GCC: Name at (1) is too long **URL:** \ **Category:** Help\ **Created:** [October 31, 2024, 11:44am UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777 "2024-10-31T11:44:48Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![jordan4ibanez](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jordan4ibanez/32/5314_2.png) [@jordan4ibanez](https://fortran-lang.discourse.group/u/jordan4ibanez)\ **Post date:** [October 31, 2024, 11:44am UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/1 "2024-10-31T11:44:48Z")
I am creating bindings for Vulkan using GCC gfortran 14.2.1 20240910 and I am having severe issues with naming variable naming in it. For example: `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR` The problem is, if I chop these to 63, there are multiple duplicates because they turn into vendor overloads for the variable names. Is there any way to get GCC to compile with this arbitrary 63 char limit removed? I have tried ```auto fpm run --flag -fmax-identifier-length=80 ``` and it completely ignores it. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [October 31, 2024, 1:06pm UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/3 "2024-10-31T13:06:42Z")
You should be seeing an error message for gfortran ```code f951: Fatal Error: Maximum supported identifier length is 63 ``` instead of truncating the names, substitution with abbreviated names via actual file edits or (if case is used consistently) using pre-processor directives might be an alternative? ``` #define VERY_LONG_VARIABLE_NAME SHORT_NAME ``` or carefully making sure nothing is changed you can use things like ``` sed -i -e 's/\/SHORTNM/g' FILENAMES ``` to replace specific names in files or abbreviate things like ``` sed - i -e 's/ACCELERATION_/ACCEL_/g' FILENAMES ``` perhaps? ---
**Author:** ![jordan4ibanez](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jordan4ibanez/32/5314_2.png) [@jordan4ibanez](https://fortran-lang.discourse.group/u/jordan4ibanez)\ **Post date:** [October 31, 2024, 1:28pm UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/4 "2024-10-31T13:28:02Z")
I appreciate that, but I am dealing with most likely tens of thousands of lines of code at the end of this so I am taking an alternative route and using static objects. It appears GCC did not expect anyone to use their program for Vulkan so I understand this. ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [October 31, 2024, 2:04pm UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/5 "2024-10-31T14:04:46Z")
We’ve come a long way since the days of 6 characters per identifier… but somehow we want more. 😆 Part of the problem is that the linker may impose limits on identifier length. I remember, when I first started using submodules with `ifort`, that I started getting warnings for things like ```fortran submodule (some_module_name) some_module_name_submodule_name contains module procedure some_procedure_name ... ``` Because the procedure name for the linker would be `some_module_name.some_module_name_submodule_name_MP_some_procedure_name_`. `ifort` issued only warnings, because it could solve the issue by chopping characters from the beginning of the identifier. But I decided it was better to just use the `sm_` prefix convention as in ```fortran submodule (some_module_name) sm_submodule_name contains module procedure some_procedure_name ... ``` You could similarly assume some conventions (I call this “getting LAPACKy”): - `STRUCTURE_TYPE` becomes `TYPE` - `STRUCTURE` becomes `STRUCT` - `ACCELERATION` becomes `ACCEL` - `PROPERTIES` becomes `PROPS` With that, the name in your example becomes `VK_TYPE_PHYSICAL_DEVICE_ACCEL_STRUCT_PROPS_KHR`. ---
**Author:** ![jordan4ibanez](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jordan4ibanez/32/5314_2.png) [@jordan4ibanez](https://fortran-lang.discourse.group/u/jordan4ibanez)\ **Post date:** [October 31, 2024, 2:10pm UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/6 "2024-10-31T14:10:49Z")
I totally understand that when Fortran was still on punch cards. But this is binding to the next version of OpenGL in modern Fortran, which will compile with no problems in the GCC C compiler. Edit: Conveyance of joking direct thought comes across as angry/aggressive in plain text so it’s removed. That naming convention seems useful, but I am attempting to make it so you can utilize the existing Khronos documentation to program with this. Having to translate through that would be quite the nightmare. ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [October 31, 2024, 2:39pm UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/7 "2024-10-31T14:39:37Z")
> [@jordan4ibanez](#): > > For example: > `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR` Looking at these enums in Vulkan, [VkStructureType(3)](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkStructureType.html), they are enough to keep me away from this library… You could introduce an intermediate type ```fortran type, private :: vk_structure_type_enum integer(c_int) :: PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR = 1000150014 ! ... end type type(vk_structure_type_enum), public, parameter :: vk_structure_type = vk_structure_type_enum() ``` And the point of access, you can use it as ```fortran print *, vk_structure_type % PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR ``` Is this stuff really meant to be used by humans, or is it meant to be used via code generation? ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [October 31, 2024, 2:56pm UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/8 "2024-10-31T14:56:05Z")
> [@ivanpribec](#): > > Is this stuff really meant to be used by humans, or is it meant to be used via code generation? This one made me laugh 😆 and thinking… who’s gonna write the code generation code itself? Humans, or another generated code? Seems like a never ending loop 😃 ---
**Author:** ![jordan4ibanez](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jordan4ibanez/32/5314_2.png) [@jordan4ibanez](https://fortran-lang.discourse.group/u/jordan4ibanez)\ **Post date:** [October 31, 2024, 2:56pm UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/9 "2024-10-31T14:56:08Z")
This is not a library, this is a graphics API that runs your GPU. This is as OpenGL, DirectX, and Metal. I have gone with this approach: [forvk/src/forvk/forvk\_parameters.f90 at master · jordan4ibanez/forvk · GitHub](https://github.com/jordan4ibanez/forvk/blob/master/src/forvk/forvk_parameters.f90#L122) This is meant to be used by humans. You are basically directly controlling the GPU. ---
**Author:** ![nja](https://avatars.discourse-cdn.com/v4/letter/n/ed8c4c/32.png) [@nja](https://fortran-lang.discourse.group/u/nja)\ **Post date:** [October 31, 2024, 6:05pm UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/10 "2024-10-31T18:05:09Z")
If I’m not mistaken, this limitation to 63 characters is speficied in section 6.2.2 of the 2023 standard. This standard increases the maximum line length and statement length to “support programs that are constructed mechanically” as noted by John Reid in his digest. Following this logic, the length limit on names could have been increased too. ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [October 31, 2024, 7:15pm UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/11 "2024-10-31T19:15:48Z")
> [@nja](#): > > Following this logic, the length limit on names could have been increased too. Maybe it will be increased if enough people suggests it with use cases and such, but I just noticed that a document in the J3 page has “2028” instead of “202y”, so I guess it’ll be at least another 4 years before the next standard. ---
**Author:** ![robert1](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/robert1/32/322_2.png) [@robert1](https://fortran-lang.discourse.group/u/robert1)\ **Post date:** [November 1, 2024, 9:34am UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/12 "2024-11-01T09:34:57Z")
I met the same problem when working with Vulkan. Therefore, I did a proposal: > > > The Fortran standard has a limit on the length of a name, i.e .the number of cha…racters: 63. Working with Vulkan give some problems as some of the named constants are (much) longer than this limit. The current core version (verson 1.2) have more than 20 of these cases. Some of the extensions also have some of that. Not only too long named constants are seen, also with a few function names. Can the limit be increased ? Maybe 127 ? ( to start with) > > Robert It is unclear to me what the status of this request is. Robert ---
**Author:** ![jordan4ibanez](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jordan4ibanez/32/5314_2.png) [@jordan4ibanez](https://fortran-lang.discourse.group/u/jordan4ibanez)\ **Post date:** [November 1, 2024, 9:50am UTC](https://fortran-lang.discourse.group/t/gcc-name-at-1-is-too-long/8777/14 "2024-11-01T09:50:11Z")
My condolences. 😛 Maybe one day we’ll see it happen. ![](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/2X/9/9d89f389d05fe8bad3d0b951eb86a588475c7541.gif)