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 472259 - Warn of conflicts of generated C identifiers
Warn of conflicts of generated C identifiers
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Code Generator
unspecified
Other All
: Normal normal
: 1.0
Assigned To: Vala maintainers
Vala maintainers
: 539489 549646 586484 614916 694236 729255 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-08-31 16:19 UTC by sam
Modified: 2018-05-22 13:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch for bug472259. (1.78 KB, patch)
2010-05-29 13:50 UTC, Rémy SAISSY
rejected Details | Review

Description sam 2007-08-31 16:19:31 UTC
A mere underscore is used to seperate class and method names in the generated C.
Try this:

/* Basic Vala Sample Code */
using GLib;

public class Sample_create : Object {
        public void widgets() {
        }
}

public class Sample : Object {
        public void create_widgets () {
        }
}

produces 2 functions called sample_create_widgets 
and therefore the generated C code is invalid.
Comment 1 Jürg Billeter 2007-08-31 16:29:00 UTC
Confirming. There should be a Vala error message to catch the problem before running the C compiler and you should be able to specify an alternative cname in an attribute.
Comment 2 Jürg Billeter 2008-09-27 09:51:59 UTC
*** Bug 539489 has been marked as a duplicate of this bug. ***
Comment 3 Jürg Billeter 2008-09-27 11:12:46 UTC
*** Bug 549646 has been marked as a duplicate of this bug. ***
Comment 4 Jürg Billeter 2009-07-29 06:22:34 UTC
*** Bug 586484 has been marked as a duplicate of this bug. ***
Comment 5 Rémy SAISSY 2010-05-28 10:20:47 UTC
(In reply to comment #1)
> Confirming. There should be a Vala error message to catch the problem before
> running the C compiler and you should be able to specify an alternative cname
> in an attribute.

Hi,
shouldn't it be better to append '_<random guid>' to every symbols generated by vala?
Comment 6 Jürg Billeter 2010-05-28 20:33:33 UTC
We certainly can't generate random identifiers for public identifiers. They need to be stable and predictable (and memorable).
Comment 7 Rémy SAISSY 2010-05-29 13:50:25 UTC
Created attachment 162268 [details] [review]
Proposed patch for bug472259.
Comment 8 Rémy SAISSY 2010-05-29 13:51:23 UTC
oops, I forgot the comment.
This is a patch for the bug.
It performs the check during the SymbolResolver step.
Comment 9 Luca Bruno 2010-07-25 09:18:01 UTC
Review of attachment 162268 [details] [review]:

Thanks for the patch. Actually the SymbolResolver has no knowledge of the C backend. Therefore that code should be somehow moved into the C code generator.
Comment 10 Jürg Billeter 2011-02-08 17:11:22 UTC
*** Bug 614916 has been marked as a duplicate of this bug. ***
Comment 11 sam 2011-04-28 15:47:32 UTC
I've read a few times that we expect GCC to be the backend for Vala.

I read this today:

4.26 Dollar Signs in Identifier Names

In GNU C, you may normally use dollar signs in identifier names. This is because many traditional C implementations allow such identifiers. However, dollar signs in identifiers are not supported on a few target machines, typically because the target assembler does not allow them. 


So... maybe we could use a dollar to join the classname to the method, instead of _ ?

If it is likely to be supported on all vala-ish platforms...

and maybe we could define symbol aliases for libraries so they don't HAVE to be troubled by the $ generally.
Comment 12 Jürg Billeter 2011-04-29 11:10:08 UTC
(In reply to comment #11)
> I've read a few times that we expect GCC to be the backend for Vala.

I don't know where you've read this but this is not true. There would be quite a few things we could simplify if we required GCC but valac doesn't require much more than C89. At least at some point people were using Vala with MSVC, Sun Studio, TinyCC, and LLVM, as far as I know.
Comment 13 Daniel Espinosa 2017-02-17 15:29:39 UTC
Your Vala Code should follow:

https://developer.gnome.org/gobject/stable/gtype-conventions.html

In this case the class's name Sample_create should be invalidated.

Then this bug should be translated to as an enhancement on code analysis and produce an warning at Code Generation phase.

Changed to 1.2 milestone.
Comment 14 Al Thomas 2017-11-12 18:36:56 UTC
(In reply to Daniel Espinosa from comment #13)
> Your Vala Code should follow:
> 
> https://developer.gnome.org/gobject/stable/gtype-conventions.html
> 
> In this case the class's name Sample_create should be invalidated.

If you mean it should be SampleCreate instead of Sample_create, then that is not documented in the page you have linked to. The closest I can find in that document is "Use the object_method pattern for function names: to invoke the method named save on an instance of object type file, call file_save". That doesn't relate to what you are saying though.

> Then this bug should be translated to as an enhancement on code analysis and
> produce an warning at Code Generation phase.
> 
> Changed to 1.2 milestone.

Vala should have robust handling of identifier names. Identifiers are a fundamental concept and should be part of any 1.0 release to my mind. Also given the number of duplicates of this bug, four have been linked, then this is an important issue to others as well. I have changed the milestone to 1.0 for those reasons.
Comment 15 Daniel Espinosa 2017-11-13 15:14:27 UTC
https://developer.gnome.org/gobject/stable/gtype-conventions.html

Prefixed type names convention is not explicitly documented.

No conventions like: 

* No [_] is allowed as a separator in type's names, so use MyObject instead of My_Object, in order to honor method's names convention.

* Prefixed type's names are convenient to avoid type conflicts. If your library or program is called Viewer, your type's name should be ViewerObject

Above is a non written convention followed by Vala.

From above link:

"Use prefixing to avoid namespace conflicts with other projects. If your library (or application) is named Viewer, prefix all your function names with viewer_. For example: viewer_object_method. "


Most projects use type names prefixing. "Object" is an accepted choice for a type name. If "Viewer" is your library or program's name, using ViewerObject is a common choice.

In the example above using SampleCreate and Sample.Create results in a namespace prefixing, so using Sample as a class name just ignores prefixing.

Sample._create is equivalent to Sample_create, so using just Sample for another classes' name, can be considered a programming error, because an inconsistent prefixing policy in the class naming.

All this should be documented in both GObject and Vala, in order to avoid that conflicts and help users to create consistent classes and method naming.
Comment 16 Al Thomas 2017-11-13 17:33:30 UTC
(In reply to Daniel Espinosa from comment #15)
> https://developer.gnome.org/gobject/stable/gtype-conventions.html
> 
> Prefixed type names convention is not explicitly documented.

That was my point, you made a misleading reference. There is no need to re-state that, but thank you for acknowledging it.

> All this should be documented in both GObject and Vala, in order to avoid
> that conflicts and help users to create consistent classes and method naming.

I don't think you can make this one disappear as a documentation bug. Personally I agree with this comment that states the goals of a 1.0 release clearly to my mind:
https://bugzilla.gnome.org/show_bug.cgi?id=531428#c13

You should also read and absorb comments #1 and #6 of this bug. They provide some limiting scope for what is required.

As far as a solution goes, I think Vala to C name translation could be done with CodeBaseModule.get_ccode_name () as part of the symbol resolver stage on the Vala AST to generate the cname and then check it is unique. Although CCodeAttribute.get_default_name () does look complex.

See also https://bugzilla.gnome.org/show_bug.cgi?id=790239
Comment 17 Rico Tzschichholz 2018-02-19 09:17:22 UTC
*** Bug 694236 has been marked as a duplicate of this bug. ***
Comment 18 Rico Tzschichholz 2018-02-19 09:18:16 UTC
*** Bug 729255 has been marked as a duplicate of this bug. ***
Comment 19 GNOME Infrastructure Team 2018-05-22 13:01:53 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/1.