Hi,
I just want to throw this out there since I already made it:
http://pastebin.geany.org/7YHWE/
It's the diff of a branch which replaces every single redundant G* type with its standard C counterpart. I have a branch with commits for each type, starting from the only one that changed (WRT to recent C99 discussions), but I just pasted here a combination patch of removing all redundantly-named, non-standard C types.
Of note is: - I left gboolean where it would break a function signature with respect to GCC warnings. - I left all guchar, gushort, guint, gulong, etc types, because, lets be honest, it's just nicer to type. - gpointer (and gconstpointer) was special because it masked the pointer * behind its typedef and so broke lines with multiple gpointer declarations on the same line (easily fixable since there's no such thing as void type in C). - I think patch includes changes to stdint types (ex. gint16, guint32) but I think we shouldn't change these as GLib assures them and the C99 standard does not in theory (and is not many in use).
I don't mean to apply this patch directly, just to spur discussion about whether Geany should be using standard C types or pointlessly typedeff'd G* types where there is an existing and cross-platform standard type.
The one big point I can see against is; "We already do like that", so there's no point in repeating it, it's totally valid and avoids (potentially, although I'm pretty sure not) breaking in obscure ways some mysterious code, but since I made the patch anyways, I'd thought I'd post it for comments. If you see some fundamental issue, of course feel free to point out.
I mostly want to solicit feedback on this topic in general rather than bikeshed my patch specifically as pasted.
P.S. I'll not proceed further on this without more input from Geany developers and community.
Cheers, Matthew Brush
Hi Matthew,
I don't know why it is worthwhile? What the advantage of char from gchar?
gchar is just for readability of the code, so why to change?
Cheers, Yosef Or Boczko
On א', אוג 18, 2013 בשעה 10:21 AM, Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
I just want to throw this out there since I already made it:
http://pastebin.geany.org/7YHWE/
It's the diff of a branch which replaces every single redundant G* type with its standard C counterpart. I have a branch with commits for each type, starting from the only one that changed (WRT to recent C99 discussions), but I just pasted here a combination patch of removing all redundantly-named, non-standard C types.
Of note is:
- I left gboolean where it would break a function signature with
respect to GCC warnings.
- I left all guchar, gushort, guint, gulong, etc types, because, lets
be honest, it's just nicer to type.
- gpointer (and gconstpointer) was special because it masked the
pointer * behind its typedef and so broke lines with multiple gpointer declarations on the same line (easily fixable since there's no such thing as void type in C).
- I think patch includes changes to stdint types (ex. gint16,
guint32) but I think we shouldn't change these as GLib assures them and the C99 standard does not in theory (and is not many in use).
I don't mean to apply this patch directly, just to spur discussion about whether Geany should be using standard C types or pointlessly typedeff'd G* types where there is an existing and cross-platform standard type.
The one big point I can see against is; "We already do like that", so there's no point in repeating it, it's totally valid and avoids (potentially, although I'm pretty sure not) breaking in obscure ways some mysterious code, but since I made the patch anyways, I'd thought I'd post it for comments. If you see some fundamental issue, of course feel free to point out.
I mostly want to solicit feedback on this topic in general rather than bikeshed my patch specifically as pasted.
P.S. I'll not proceed further on this without more input from Geany developers and community.
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13-08-18 12:21 AM, Matthew Brush wrote:
Hi,
I just want to throw this out there since I already made it:
http://pastebin.geany.org/7YHWE/
It's the diff of a branch which replaces every single redundant G* type with its standard C counterpart. I have a branch with commits for each type, starting from the only one that changed (WRT to recent C99 discussions), but I just pasted here a combination patch of removing all redundantly-named, non-standard C types.
Of note is:
- I left gboolean where it would break a function signature with respect
to GCC warnings.
- I left all guchar, gushort, guint, gulong, etc types, because, lets be
honest, it's just nicer to type.
- gpointer (and gconstpointer) was special because it masked the pointer
- behind its typedef and so broke lines with multiple gpointer
declarations on the same line (easily fixable since there's no such thing as void type in C).
- I think patch includes changes to stdint types (ex. gint16, guint32)
but I think we shouldn't change these as GLib assures them and the C99 standard does not in theory (and is not many in use).
I don't mean to apply this patch directly, just to spur discussion about whether Geany should be using standard C types or pointlessly typedeff'd G* types where there is an existing and cross-platform standard type.
The one big point I can see against is; "We already do like that", so there's no point in repeating it, it's totally valid and avoids (potentially, although I'm pretty sure not) breaking in obscure ways some mysterious code, but since I made the patch anyways, I'd thought I'd post it for comments. If you see some fundamental issue, of course feel free to point out.
I mostly want to solicit feedback on this topic in general rather than bikeshed my patch specifically as pasted.
P.S. I'll not proceed further on this without more input from Geany developers and community.
Just to add some relevant links:
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03474.html http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03397.html http://webcache.googleusercontent.com/search?q=cache:OszwDROZX4oJ:https://li... http://wiki.inkscape.org/wiki/index.php/Booleans http://webcache.googleusercontent.com/search?q=cache:l64BmXlu-doJ:permalink....
Cheers, Matthew Brush
Hi,
It was pointed out to me on IRC that I went into too much details/patches and muddied the original question, so I propose it again more simply:
"Do you agree it would be better for Geany to use standard C types as opposed to GLib types which are typedef'd to the exact same thing?" (ex. gint->int, glong->long, gchar->char etc.)
Sorry for any noise, Matthew Brush
On 13-08-18 01:32 AM, Matthew Brush wrote:
On 13-08-18 12:21 AM, Matthew Brush wrote:
Hi,
I just want to throw this out there since I already made it:
http://pastebin.geany.org/7YHWE/
It's the diff of a branch which replaces every single redundant G* type with its standard C counterpart. I have a branch with commits for each type, starting from the only one that changed (WRT to recent C99 discussions), but I just pasted here a combination patch of removing all redundantly-named, non-standard C types.
Of note is:
- I left gboolean where it would break a function signature with respect
to GCC warnings.
- I left all guchar, gushort, guint, gulong, etc types, because, lets be
honest, it's just nicer to type.
- gpointer (and gconstpointer) was special because it masked the pointer
- behind its typedef and so broke lines with multiple gpointer
declarations on the same line (easily fixable since there's no such thing as void type in C).
- I think patch includes changes to stdint types (ex. gint16, guint32)
but I think we shouldn't change these as GLib assures them and the C99 standard does not in theory (and is not many in use).
I don't mean to apply this patch directly, just to spur discussion about whether Geany should be using standard C types or pointlessly typedeff'd G* types where there is an existing and cross-platform standard type.
The one big point I can see against is; "We already do like that", so there's no point in repeating it, it's totally valid and avoids (potentially, although I'm pretty sure not) breaking in obscure ways some mysterious code, but since I made the patch anyways, I'd thought I'd post it for comments. If you see some fundamental issue, of course feel free to point out.
I mostly want to solicit feedback on this topic in general rather than bikeshed my patch specifically as pasted.
P.S. I'll not proceed further on this without more input from Geany developers and community.
Just to add some relevant links:
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03474.html http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03397.html http://webcache.googleusercontent.com/search?q=cache:OszwDROZX4oJ:https://li...
http://wiki.inkscape.org/wiki/index.php/Booleans http://webcache.googleusercontent.com/search?q=cache:l64BmXlu-doJ:permalink....
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Sun, 18 Aug 2013 02:32:34 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
"Do you agree it would be better for Geany to use standard C types as opposed to GLib types which are typedef'd to the exact same thing?" (ex. gint->int, glong->long, gchar->char etc.)
Yes.
- I left gboolean where it would break a function signature with respect
to GCC warnings.
Understandable.
- I left all guchar, gushort, guint, gulong, etc types, because, lets be
honest, it's just nicer to type.
In my Geany [2013-06-16], there are 43 guchar, gushort and gulong; 475 guint, 1420 gint and 2091 gchar. It is easier to type guint instead of unsigned - the keys are near - but it is worth to mix the standard and GLib types?
Personally I'm using gchar if a string may be UTF-8, and char where it's guaranteed to be ASCII or it's unknown and doesn't matter - to remind me that such string is logically not a direct array of char.
- I think patch includes changes to stdint types (ex. gint16, guint32)
but I think we shouldn't change these as GLib assures them and the C99 standard does not in theory (and is not many in use).
AFAIK GLib does not emulate unexistent integer types. If they exist && we are using C99, they will be defined as u/intN_t.
--
IMHO, Colomban summed up pretty well why there's no compelling reason to adopt C99. My 2 euro-cents:
I think I missed this summation, will re-read thread.
The entire mail from Sat, 17 Aug 2013 09:07 +0000. Though you will probably disagree it's a nice summary, that's subjective.
- If you think that everyone who completed university in the last 14
years uses C99, that's not quite the case. [...]
The smiley face in the sentence you didn't quote but are responding to means I was joking/being sarcastic.
Sorry, missed that. I read the entire discussion at once.
Now to change my opinion somewhat: I'm not against C99 if we kill the redundant g* definitions. I simply don't like them.
We'd better keep gboolean if bool generates warnings, since it has a logical meaning, and I'll keep gchar in Scope for the same reason.
On 18 August 2013 19:32, Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
It was pointed out to me on IRC that I went into too much details/patches and muddied the original question, so I propose it again more simply:
"Do you agree it would be better for Geany to use standard C types as opposed to GLib types which are typedef'd to the exact same thing?" (ex. gint->int, glong->long, gchar->char etc.)
Personally I can't find any great positives or negatives, but then I've trained my eyes to read gint as int, others may find standard code more attractive (or vice versa).
What I would be worried about is changing the existing code to use the standard types. Matthew has kindly illustrated the size of such a change, and while I'm sure 99.99% of the changes are fine, I would worry about the few places it might not be semantically equivalent, no matter how good the regexes that made the change are. The size of the change means we are never going to manually inspect it, and the places it will go wrong are not obvious, so we can't easily point to examples.
So whilst I wouldn't advocate changing the existing code (at least en bloc) I don't see any reason for disallowing standard types in new code and changes to existing code as it is touched.
Cheers Lex
Sorry for any noise, Matthew Brush
On Sun, 18 Aug 2013 02:32:34 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
"Do you agree it would be better for Geany to use standard C types as opposed to GLib types which are typedef'd to the exact same thing?" (ex. gint->int, glong->long, gchar->char etc.)
To be honest, I don't have a strong opinion. For gint etc. I was using most likly because I was in the g<foo>-mode ... But I don't have a porlbem using int in future..
But: I'd like to have it in one style for Geany core as well as Geany-plugins in future.
Cheers, Frank
On 13-08-18 03:49 AM, Lex Trotman wrote:
On 18 August 2013 19:32, Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
It was pointed out to me on IRC that I went into too much details/patches and muddied the original question, so I propose it again more simply:
"Do you agree it would be better for Geany to use standard C types as opposed to GLib types which are typedef'd to the exact same thing?" (ex. gint->int, glong->long, gchar->char etc.)
Personally I can't find any great positives or negatives, but then I've trained my eyes to read gint as int, others may find standard code more attractive (or vice versa).
What I would be worried about is changing the existing code to use the standard types. Matthew has kindly illustrated the size of such a change, and while I'm sure 99.99% of the changes are fine, I would worry about the few places it might not be semantically equivalent, no matter how good the regexes that made the change are. The size of the change means we are never going to manually inspect it, and the places it will go wrong are not obvious, so we can't easily point to examples.
I think you could manually reason about the changes though, the actual branch is of course a series of steps along the way (as opposed to monolithic patch dumped here) and excluding gboolean->_Bool, I don't think any of the semantics changed (based on studying of GLib headers).
So whilst I wouldn't advocate changing the existing code (at least en bloc) I don't see any reason for disallowing standard types in new code and changes to existing code as it is touched.
The main thing here is consistency across the codebase, I guess.
Cheers, Matthew Brush
On 13-08-18 03:34 AM, Dimitar Zhekov wrote:
On Sun, 18 Aug 2013 02:32:34 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
"Do you agree it would be better for Geany to use standard C types as opposed to GLib types which are typedef'd to the exact same thing?" (ex. gint->int, glong->long, gchar->char etc.)
Yes.
- I left gboolean where it would break a function signature with respect
to GCC warnings.
Understandable.
- I left all guchar, gushort, guint, gulong, etc types, because, lets be
honest, it's just nicer to type.
In my Geany [2013-06-16], there are 43 guchar, gushort and gulong; 475 guint, 1420 gint and 2091 gchar. It is easier to type guint instead of unsigned - the keys are near - but it is worth to mix the standard and GLib types?
Personally I'm using gchar if a string may be UTF-8, and char where it's guaranteed to be ASCII or it's unknown and doesn't matter - to remind me that such string is logically not a direct array of char.
That sounds like quite a useful differentiation.
- I think patch includes changes to stdint types (ex. gint16, guint32)
but I think we shouldn't change these as GLib assures them and the C99 standard does not in theory (and is not many in use).
AFAIK GLib does not emulate unexistent integer types. If they exist && we are using C99, they will be defined as u/intN_t.
I thought this too, but it seems that glibconfig.h (or similarly named header, generated from glib configure.ac using lots of shell magic), is not ever using C99/stdint.h types even if they exists - at least according to ebassi (core dev). They just always figure out the right sized type using shell and preprocessor magic.
My concern here with stdint.h was that if CHAR_BIT > 8 then C99 forbids an implementation from defining int8_t and if int8_t isn't defined then uint8_t can't be defined. And if this is true [citation needed], and you couldn't rely on (u)int8_t, then might as well just stick to portable GLib typedefs.
Cheers, Matthew Brush
Short version: No. Just no.
Le 18/08/2013 09:21, Matthew Brush a écrit :
Hi,
I just want to throw this out there since I already made it:
http://pastebin.geany.org/7YHWE/
It's the diff of a branch which replaces every single redundant G* type with its standard C counterpart. I have a branch with commits for each type, starting from the only one that changed (WRT to recent C99 discussions), but I just pasted here a combination patch of removing all redundantly-named, non-standard C types.
Of note is:
- I left gboolean where it would break a function signature with respect
to GCC warnings.
- I left all guchar, gushort, guint, gulong, etc types, because, lets be
honest, it's just nicer to type.
Nice, we have "int" and "guint"? Come on.
- gpointer (and gconstpointer) was special because it masked the pointer
- behind its typedef and so broke lines with multiple gpointer
declarations on the same line (easily fixable since there's no such thing as void type in C).
- I think patch includes changes to stdint types (ex. gint16, guint32)
but I think we shouldn't change these as GLib assures them and the C99 standard does not in theory (and is not many in use).
int and gint32? Come one.
I don't mean to apply this patch directly, just to spur discussion about whether Geany should be using standard C types or pointlessly typedeff'd G* types where there is an existing and cross-platform standard type.
No.
The one big point I can see against is; "We already do like that", so there's no point in repeating it, it's totally valid and avoids (potentially, although I'm pretty sure not) breaking in obscure ways some mysterious code, but since I made the patch anyways, I'd thought I'd post it for comments. If you see some fundamental issue, of course feel free to point out.
Fundamental issues: uselessness, ugly mix between int, guint, unsigned int, guint32, bool, int, gboolean, etc.
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03474.html
Angry guy is angry.
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03397.html
…this is a reason NOT TO start using C99's bool and have mixed stuff we have no idea about.
http://webcache.googleusercontent.com/search?q=cache:OszwDROZX4oJ:https://li... http://wiki.inkscape.org/wiki/index.php/Booleans
Read this, don't put trash in your variables and don't compare ==TRUE or ==FALSE, it's ugly anyway.
http://webcache.googleusercontent.com/search?q=cache:l64BmXlu-doJ:permalink....
And they use a NEW type, CoglBool? Come on.
Regards, Colomban
I mostly want to solicit feedback on this topic in general rather than bikeshed my patch specifically as pasted.
P.S. I'll not proceed further on this without more input from Geany developers and community.
Cheers, Matthew Brush
On 13-08-18 04:24 AM, Colomban Wendling wrote:
Short version: No. Just no.
Le 18/08/2013 09:21, Matthew Brush a écrit :
Hi,
I just want to throw this out there since I already made it:
http://pastebin.geany.org/7YHWE/
It's the diff of a branch which replaces every single redundant G* type with its standard C counterpart. I have a branch with commits for each type, starting from the only one that changed (WRT to recent C99 discussions), but I just pasted here a combination patch of removing all redundantly-named, non-standard C types.
Of note is:
- I left gboolean where it would break a function signature with respect
to GCC warnings.
- I left all guchar, gushort, guint, gulong, etc types, because, lets be
honest, it's just nicer to type.
Nice, we have "int" and "guint"? Come on.
We could use the more common (but not) standard uint or such.
- gpointer (and gconstpointer) was special because it masked the pointer
- behind its typedef and so broke lines with multiple gpointer
declarations on the same line (easily fixable since there's no such thing as void type in C).
- I think patch includes changes to stdint types (ex. gint16, guint32)
but I think we shouldn't change these as GLib assures them and the C99 standard does not in theory (and is not many in use).
int and gint32? Come one.
gint32 is a special fixed-width integer, but we could replace with int32_t (probably reliable with autoconf).
I don't mean to apply this patch directly, just to spur discussion about whether Geany should be using standard C types or pointlessly typedeff'd G* types where there is an existing and cross-platform standard type.
No.
That's constructive.
The one big point I can see against is; "We already do like that", so there's no point in repeating it, it's totally valid and avoids (potentially, although I'm pretty sure not) breaking in obscure ways some mysterious code, but since I made the patch anyways, I'd thought I'd post it for comments. If you see some fundamental issue, of course feel free to point out.
Fundamental issues: uselessness, ugly mix between int, guint, unsigned int, guint32, bool, int, gboolean, etc.
Well I agree about consistency between short, int, long and gshort, gint, glong, but I left basically for your sake to avoid bikeshedding about how guint is so much easier to type than the completely standard since forever 'unsigned'. (or 'unsigned int' if you would).
As I mentioned on IRC, I don't attempt to update Geany's codebase in one fell swoop, just to facilitate use standard C instead of G* stuffs (where it serves no purpose) again.
Cheers, Matthew Brush
On 13-08-18 12:36 AM, Yosef Or Boczko wrote:
Hi Matthew,
I don't know why it is worthwhile? What the advantage of char from gchar?
char is a completely standard data type since the beginning of C. Why typedef it to some other type (especially when not providing any platform independence like whether it's signed or unsigned)?
gchar is just for readability of the code, so why to change?
How is gchar more readable than char?
Cheers, Matthew Brush
On Sun, 18 Aug 2013 03:56:01 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
My concern here with stdint.h was that if CHAR_BIT > 8 then C99 forbids an implementation from defining int8_t and if int8_t isn't defined then uint8_t can't be defined. And if this is true [citation needed], and you couldn't rely on (u)int8_t, then might as well just stick to portable GLib typedefs.
In POSIX and Windows, CHAR_BIT is always 8, and we don't really support anything else.
CHAR_BIT may be > 8 if the system can not address 8-bit values, but in that case, no 8-bit integer type will exist, and GLib will be unable to define a gint8 either. Which is not a problem, since GLib (as of 2.37) supports only G_OS_BEOS, G_OS_UNIX and G_OS_WIN32...
On 13-08-19 10:33 AM, Dimitar Zhekov wrote:
On Sun, 18 Aug 2013 03:56:01 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
My concern here with stdint.h was that if CHAR_BIT > 8 then C99 forbids an implementation from defining int8_t and if int8_t isn't defined then uint8_t can't be defined. And if this is true [citation needed], and you couldn't rely on (u)int8_t, then might as well just stick to portable GLib typedefs.
In POSIX and Windows, CHAR_BIT is always 8, and we don't really support anything else.
CHAR_BIT may be > 8 if the system can not address 8-bit values, but in that case, no 8-bit integer type will exist, and GLib will be unable to define a gint8 either. Which is not a problem, since GLib (as of 2.37) supports only G_OS_BEOS, G_OS_UNIX and G_OS_WIN32...
Thanks for the info, good to know!
I'm still +1 for using the standard types over the weird G* types, but I'll stop annoying everyone about it if others like them (for reasons I didn't understand). Maybe I'll ask again about it maybe once we're ready to switch to C11 in a decade or so :)
Cheers, Matthew Brush