Re: [freetype2-demos] Fix compiler warnings
There are tools like towncrier and probably others where your patches are accompanied by news fragments in a news dir that are assembled into a news file and then cleared on release.
Re: Build system considerations
> > I apologize if somebody felt personally wronged by my comment. > > Since I don't see anything wrong with it, I would be very happy if you could > please explain what's wrong with it so I can try to improve myself in the > future. Rather easy. I am sure this is not how you communicate with people who you barely know, say, in a supermarket or a scientific conference. We all should strive to remain civil even when before you are in your pajamas before you go to bed. When you are in front of your monitor, you are in public.
Re: [freetype2-demos] Fix compiler warnings
> > Yes, it seems a bit odd these days, but I'll let Werner be the judge > > on that :-) > > The main reason to maintain a ChangeLog file in the strict Emacs-like > format is that you have to concentrate on adding good descriptions. > Writing a sloppy one-liner while doing `git commit` is far too easy. The damb^H^H^H^H linear nature of ChangeLog clashes with git: you cannot easily merge from branches without a merge conflict in the damn^H^H^H^H sequential ChangeLog. There must be a compromise: GCC is extremely disciplined without ChangeLog. We can do it too.
Re: [freetype2-demos] Fix compiler warnings
>> We still use Emacs style for commit messages > > I'm not sure what that means. I've updated the commit message to > look like what is currently in the git log. He means that we still maintain a ChangeLog file. >> and track them in ChangeLog, which is debatable > > Yes, it seems a bit odd these days, but I'll let Werner be the judge > on that :-) The main reason to maintain a ChangeLog file in the strict Emacs-like format is that you have to concentrate on adding good descriptions. Writing a sloppy one-liner while doing `git commit` is far too easy. Werner
Re: [freetype2-demos] Fix compiler warnings
Le ven. 1 mai 2020 à 13:53, Alexei Podtelezhnikov a
écrit :
>
> This should fix https://savannah.nongnu.org/bugs/?58275
>
> <0001-Fix-compilation-warnings.patch>
>
>
> We still use Emacs style for commit messages
>
I'm not sure what that means. I've updated the commit message to look like
what is currently in the git log.
> and track them in ChangeLog, which is debatable
>
> Yes, it seems a bit odd these days, but I'll let Werner be the judge on
that :-)
From 1b44f35d259622ebb837d9d00833502ac751df13 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Thu, 30 Apr 2020 02:12:59 +0200
Subject: [build] Fix compilation warnings
Fix various compiler warnings when building the FreeType 2
demo programs:
* graph/x11/grx11.c: Changed the return type of
gr_x11_surface_listen_event() to match the expected type.
* src/: Remove problematic uses of strncpy() and replace
them with snprintf() which takes the size of the target
buffer and remove un-needed uses of the alt_filename[]
array.
Reported as https://savannah.nongnu.org/bugs/?58275
---
graph/x11/grx11.c | 4 +++-
src/compos.c | 17 +
src/ftchkwd.c | 16
src/ftdump.c | 16
src/ftlint.c | 17 +
src/ftmemchk.c| 17 +
src/ftsbit.c | 14 --
src/fttimer.c | 14 ++
src/fttry.c | 13 ++---
9 files changed, 34 insertions(+), 94 deletions(-)
diff --git a/graph/x11/grx11.c b/graph/x11/grx11.c
index c923e0a..9bca06b 100644
--- a/graph/x11/grx11.c
+++ b/graph/x11/grx11.c
@@ -1148,7 +1148,7 @@ typedef unsigned long uint32;
}
- static void
+ static int
gr_x11_surface_listen_event( grX11Surface* surface,
intevent_mask,
grEvent* grevent )
@@ -1237,6 +1237,8 @@ typedef unsigned long uint32;
Set_Key:
grevent->type = gr_key_down;
grevent->key = grkey;
+
+return 1;
}
diff --git a/src/compos.c b/src/compos.c
index 46ee2ae..a4cdd87 100644
--- a/src/compos.c
+++ b/src/compos.c
@@ -65,7 +65,6 @@
int i, file_index;
unsigned int id;
char filename[1024 + 4];
-char alt_filename[1024 + 4];
char* execname;
char* fname;
@@ -90,19 +89,13 @@
i--;
}
- filename[1024] = '\0';
- alt_filename[1024] = '\0';
-
- strncpy( filename, fname, 1024 );
- strncpy( alt_filename, fname, 1024 );
-
#ifndef macintosh
- if ( i >= 0 )
- {
-strncpy( filename + strlen( filename ), ".ttf", 4 );
-strncpy( alt_filename + strlen( alt_filename ), ".ttc", 4 );
- }
+ snprintf(filename, sizeof(filename), "%s%s", fname,
+ (i >= 0 ? ".ttf" : ""));
+#else
+ snprintf(filename, sizeof(filename), "%s", fname);
#endif
+
i = strlen( filename );
fname = filename;
diff --git a/src/ftchkwd.c b/src/ftchkwd.c
index 7673847..46194a0 100644
--- a/src/ftchkwd.c
+++ b/src/ftchkwd.c
@@ -119,7 +119,6 @@
int i, file_index;
charfilename[1024 + 4];
-charalt_filename[1024 + 4];
char* execname;
char* fname;
@@ -160,18 +159,11 @@
i--;
}
- filename[1024] = '\0';
- alt_filename[1024] = '\0';
-
- strncpy( filename, fname, 1024 );
- strncpy( alt_filename, fname, 1024 );
-
#ifndef macintosh
- if ( i >= 0 )
- {
-strncpy( filename + strlen( filename ), ".ttf", 4 );
-strncpy( alt_filename + strlen( alt_filename ), ".ttc", 4 );
- }
+ snprintf(filename, sizeof(filename), "%s%s", fname,
+ (i >= 0 ? ".ttf" : ""));
+#else
+ snprintf(filename, sizeof(filename), "%s", fname);
#endif
/* Load face */
diff --git a/src/ftdump.c b/src/ftdump.c
index 56c4672..9015d66 100644
--- a/src/ftdump.c
+++ b/src/ftdump.c
@@ -857,7 +857,6 @@
{
inti, file;
char filename[1024];
-char alt_filename[1024];
char* execname;
intnum_faces;
intoption;
@@ -935,12 +934,6 @@
file = 0;
-strncpy( filename, argv[file], 1019 );
-strncpy( alt_filename, argv[file], 1019 );
-
-filename[1019] = '\0';
-alt_filename[1019] = '\0';
-
/* try to load the file name as is, first */
error = FT_New_Face( library, argv[file], 0, );
if ( !error )
@@ -955,11 +948,10 @@
i--;
}
-if ( i >= 0 )
-{
- strncpy( filename + strlen( filename ), ".ttf", 5 );
- strncpy( alt_filename + strlen( alt_filename ), ".ttc", 5 );
-}
+snprintf(filename, sizeof(filename), "%s%s", argv[file],
+ (i >= 0 ? ".ttf" : ""));
+#else
+snprintf(filename, sizeof(filename), "%s", argv[file]);
#endif
/* Load face */
diff --git a/src/ftlint.c b/src/ftlint.c
index 02bb4e6..cdb0473 100644
--- a/src/ftlint.c
+++ b/src/ftlint.c
@@ -63,7 +63,6 @@
int
Re: [freetype2-demos] Fix compiler warnings
> This patches removes a few compiler warnings when building the > FreeType 2 demo programs. It also replaces a few strncpy() calls > with snprintf() for safety / simplicity. Thanks a lot! Now committed. Werner
Re: [freetype2-demos] Fix compiler warnings
> This should fix https://savannah.nongnu.org/bugs/?58275 > <0001-Fix-compilation-warnings.patch> We still use Emacs style for commit messages and track them in ChangeLog, which is debatable
[freetype2-demos] Fix compiler warnings
This patches removes a few compiler warnings when building the FreeType 2
demo programs.
It also replaces a few strncpy() calls with snprintf() for safety /
simplicity.
This should fix https://savannah.nongnu.org/bugs/?58275
From 33ebbd7333d10a5dbac6cac9c37c95a573e24e80 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Thu, 30 Apr 2020 02:12:59 +0200
Subject: Fix compilation warnings
Fix various compiler warnings when building the FreeType 2
demo programs:
- graph/x11/grx11.c: Changed the return type of
gr_x11_surface_listen_event() to match the expected type.
- src/: Remove problematic uses of strncpy() and replace
them with snprintf() which takes the size of the target
buffer and remove un-needed uses of the alt_filename[]
array.
Bug: 58257
---
graph/x11/grx11.c | 4 +++-
src/compos.c | 17 +
src/ftchkwd.c | 16
src/ftdump.c | 16
src/ftlint.c | 17 +
src/ftmemchk.c| 17 +
src/ftsbit.c | 14 --
src/fttimer.c | 14 ++
src/fttry.c | 13 ++---
9 files changed, 34 insertions(+), 94 deletions(-)
diff --git a/graph/x11/grx11.c b/graph/x11/grx11.c
index c923e0a..9bca06b 100644
--- a/graph/x11/grx11.c
+++ b/graph/x11/grx11.c
@@ -1148,7 +1148,7 @@ typedef unsigned long uint32;
}
- static void
+ static int
gr_x11_surface_listen_event( grX11Surface* surface,
intevent_mask,
grEvent* grevent )
@@ -1237,6 +1237,8 @@ typedef unsigned long uint32;
Set_Key:
grevent->type = gr_key_down;
grevent->key = grkey;
+
+return 1;
}
diff --git a/src/compos.c b/src/compos.c
index 46ee2ae..a4cdd87 100644
--- a/src/compos.c
+++ b/src/compos.c
@@ -65,7 +65,6 @@
int i, file_index;
unsigned int id;
char filename[1024 + 4];
-char alt_filename[1024 + 4];
char* execname;
char* fname;
@@ -90,19 +89,13 @@
i--;
}
- filename[1024] = '\0';
- alt_filename[1024] = '\0';
-
- strncpy( filename, fname, 1024 );
- strncpy( alt_filename, fname, 1024 );
-
#ifndef macintosh
- if ( i >= 0 )
- {
-strncpy( filename + strlen( filename ), ".ttf", 4 );
-strncpy( alt_filename + strlen( alt_filename ), ".ttc", 4 );
- }
+ snprintf(filename, sizeof(filename), "%s%s", fname,
+ (i >= 0 ? ".ttf" : ""));
+#else
+ snprintf(filename, sizeof(filename), "%s", fname);
#endif
+
i = strlen( filename );
fname = filename;
diff --git a/src/ftchkwd.c b/src/ftchkwd.c
index 7673847..46194a0 100644
--- a/src/ftchkwd.c
+++ b/src/ftchkwd.c
@@ -119,7 +119,6 @@
int i, file_index;
charfilename[1024 + 4];
-charalt_filename[1024 + 4];
char* execname;
char* fname;
@@ -160,18 +159,11 @@
i--;
}
- filename[1024] = '\0';
- alt_filename[1024] = '\0';
-
- strncpy( filename, fname, 1024 );
- strncpy( alt_filename, fname, 1024 );
-
#ifndef macintosh
- if ( i >= 0 )
- {
-strncpy( filename + strlen( filename ), ".ttf", 4 );
-strncpy( alt_filename + strlen( alt_filename ), ".ttc", 4 );
- }
+ snprintf(filename, sizeof(filename), "%s%s", fname,
+ (i >= 0 ? ".ttf" : ""));
+#else
+ snprintf(filename, sizeof(filename), "%s", fname);
#endif
/* Load face */
diff --git a/src/ftdump.c b/src/ftdump.c
index 56c4672..9015d66 100644
--- a/src/ftdump.c
+++ b/src/ftdump.c
@@ -857,7 +857,6 @@
{
inti, file;
char filename[1024];
-char alt_filename[1024];
char* execname;
intnum_faces;
intoption;
@@ -935,12 +934,6 @@
file = 0;
-strncpy( filename, argv[file], 1019 );
-strncpy( alt_filename, argv[file], 1019 );
-
-filename[1019] = '\0';
-alt_filename[1019] = '\0';
-
/* try to load the file name as is, first */
error = FT_New_Face( library, argv[file], 0, );
if ( !error )
@@ -955,11 +948,10 @@
i--;
}
-if ( i >= 0 )
-{
- strncpy( filename + strlen( filename ), ".ttf", 5 );
- strncpy( alt_filename + strlen( alt_filename ), ".ttc", 5 );
-}
+snprintf(filename, sizeof(filename), "%s%s", argv[file],
+ (i >= 0 ? ".ttf" : ""));
+#else
+snprintf(filename, sizeof(filename), "%s", argv[file]);
#endif
/* Load face */
diff --git a/src/ftlint.c b/src/ftlint.c
index 02bb4e6..cdb0473 100644
--- a/src/ftlint.c
+++ b/src/ftlint.c
@@ -63,7 +63,6 @@
int i, file_index;
unsigned int id;
char filename[1024];
-char alt_filename[1024];
char* execname;
char* fname;
@@ -110,19 +109,13 @@
i--;
}
- strncpy( filename, fname, 1019 );
- strncpy(
Re: [patches] Minor build system improvements
Yes, none of that is urgent :) Feel free to not push them to master for now (branch or no branch). I'd still value your input on the content though, hope it's not too scary :) Le ven. 1 mai 2020 à 10:25, Werner LEMBERG a écrit : > > > Here are two cumulative patches that try to simplify the rules.mk > > and module.mk used by the FreeType 2 build system. [...] > > Thanks a lot, will check them soon! > > Since I'm going to cut a new release soon I wonder whether it makes > sense to put this patch temporarily into a branch, avoiding issues > shortly before the new version... > > > Werner >
Re: Build system considerations
Le ven. 1 mai 2020 à 10:12, Albert Astals Cid a écrit : > > > I apologize if somebody felt personally wronged by my comment. > > Since I don't see anything wrong with it, I would be very happy if you > could please explain what's wrong with it so I can try to improve myself in > the future. > > Sure, "life bubble" is essentially a reference to the poster's private life, which seems irrelevant here. "very biased" sounds judgemental, using it in other contexts may be completely appropriate, but in this specific one, looks like you may be trying to attack the poster's character instead of the point he's trying to make. That may not be what you tried to express, but I guarantee you that's how it is perceived. It is likely that you misread Behdad's post (which was *indeed* a bit ambiguous) and drew conclusions too quickly, assuming either ill-intent or incompetence, but I encourage you to find better ways to react to this kind of situation in the future. Also don't worry too much about it, we all make mistakes, me included, and the Internet is an unforgiving place where many of the bad decisions we make on public lists are written in stone and searchable decades to come. I hope you'll still be happy to contribute to the discussion after this :) - David > Best Regards, > Albert > > >
Re: [Freetype-devel] Re: Build system considerations
> [...] I'm interested in the decision under a situation: if harfbuzz > requires libstdc++, should we care the dependency of FreeType? Please elaborate. Given that FreeType is a C library it's not clear to me why there should be an issue – FreeType happily works without HarfBuzz (then with reduced capabilities, of course). Werner
Re: [patches] Minor build system improvements
> Here are two cumulative patches that try to simplify the rules.mk > and module.mk used by the FreeType 2 build system. [...] Thanks a lot, will check them soon! Since I'm going to cut a new release soon I wonder whether it makes sense to put this patch temporarily into a branch, avoiding issues shortly before the new version... Werner
Re: Build system considerations
El divendres, 1 de maig de 2020, a les 0:52:16 CEST, David Turner va escriure: > Le jeu. 30 avr. 2020 à 23:33, Albert Astals Cid a écrit : > > > El dijous, 30 d’abril de 2020, a les 19:35:19 CEST, Behdad Esfahbod va > > escriure: > > > Hi David, > > > > > > Thanks for bringing this up. I come from the GNOME camp. My > > understanding > > > is that meson is replacing autotools longterm, sidestepping attempts like > > > cmake, the same way that git replaced CVS, sidestepping mercurial, > > bazaar, > > > etc. > > > > I am afraid that is your very biased life bubble. > > I'm not sure you realize that what you wrote sounds insensitive and is > bordering ad-hominen. > You could have said that you disagree and that this doesn't match your > experience for example. > Instead you tone devalues the point you're trying to make. I apologize if somebody felt personally wronged by my comment. Since I don't see anything wrong with it, I would be very happy if you could please explain what's wrong with it so I can try to improve myself in the future. Best Regards, Albert
