After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 469335 - Variables in generated code might conflict with user code
Variables in generated code might conflict with user code
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Methods
0.1.x
Other All
: Normal minor
: ---
Assigned To: Jürg Billeter
Vala maintainers
: 477326 508450 530698 537032 572992 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-08-22 17:55 UTC by Andreas Obergrusberger
Modified: 2009-04-14 18:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Andreas Obergrusberger 2007-08-22 17:55:20 UTC 
Please describe the problem:
Vala generates code with char* __temp0 and so on.
This might conflict with __temp0 from user code.
Nothing life threatening. Still this might cause a sleepless night for an unexperienced user.

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Jürg Billeter 2007-08-27 15:06:22 UTC 
Yes, we should ensure that generated variable names never conflict in the C code. We should also avoid the __ prefix as that's reserved for the C compiler implementation.
Comment 2 Mathias Hasselmann (IRC: tbf) 2007-08-28 07:05:47 UTC 
What about replacing the "__" prefix with "__valac_"? Vala is a compiler, so it might be ok to inject stuff in the compiler namespace. Well, and I doubt any C compiler ever will introduce some "__valac_" prefixed variables expect for sabotaging valac. 

Regarding the conflict: I guess valac should just reject symbols with a double underscore. As you pointed out: The "__" namespace is reserved for compilers...
Comment 3 Andreas Obergrusberger 2007-08-28 09:58:21 UTC 
(In reply to comment #2)
> What about replacing the "__" prefix with "__valac_"? Vala is a compiler, so it
> might be ok to inject stuff in the compiler namespace. Well, and I doubt any C
> compiler ever will introduce some "__valac_" prefixed variables expect for
> sabotaging valac. 
> 
> Regarding the conflict: I guess valac should just reject symbols with a double
> underscore. As you pointed out: The "__" namespace is reserved for compilers...
> 

A combination of those two solution would be perfect imo.
Comment 4 Jürg Billeter 2007-09-18 21:09:29 UTC 
*** Bug 477326 has been marked as a duplicate of this bug. ***
Comment 5 Jürg Billeter 2008-01-18 17:59:54 UTC 
*** Bug 508450 has been marked as a duplicate of this bug. ***
Comment 6 Jürg Billeter 2008-05-10 19:25:49 UTC 
*** Bug 530698 has been marked as a duplicate of this bug. ***
Comment 7 Jürg Billeter 2008-10-09 21:31:02 UTC 
*** Bug 537032 has been marked as a duplicate of this bug. ***
Comment 8 Jürg Billeter 2009-04-10 08:31:19 UTC 
commit 74cb5c7d6d1df95f7779f84b58f31ceeab5417ad
Author: Jürg Billeter <j@bitron.ch>
Date:   Fri Apr 10 10:27:11 2009 +0200

    Improve handling of reserved identifiers
    
    Avoid conflicts between reserved identifiers and generated code
    for local variables and formal parameters. Fixes bug 469335 and
    bug 515225.
Comment 9 Jürg Billeter 2009-04-14 18:24:41 UTC 
*** Bug 572992 has been marked as a duplicate of this bug. ***