[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/3] Various clean up in preparation for libtextstyle
From: |
Akim Demaille |
Subject: |
Re: [PATCH 0/3] Various clean up in preparation for libtextstyle |
Date: |
Fri, 22 Mar 2019 20:19:37 +0100 |
Hi Bruno,
I missed your message, sorry!
> Le 20 mars 2019 à 02:25, Bruno Haible <address@hidden> a écrit :
>
>> I have checked that the file you sent was sufficient to cover
>> Bison's needs, and it's almost perfect:
>
> Thanks, I have added it as a module to gnulib. With the _GL_UNUSED markers
> and some other tweaks.
I'm installing this for the last missing bit:
commit 56ac5495091fdd233a07c95602ff595bbe536cc9
Author: Akim Demaille <address@hidden>
Date: Fri Mar 22 20:05:46 2019 +0100
libtextstyle-optional: Fix compiler warnings.
* lib/textstyle.in.h (html_styled_ostream_create): Flag arguments
as unused.
diff --git a/ChangeLog b/ChangeLog
index 62c522e65..457caa9ad 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2019-03-22 Akim Demaille <address@hidden>
+
+ libtextstyle-optional: Fix compiler warnings.
+ * lib/textstyle.in.h (html_styled_ostream_create): Flag arguments
+ as unused.
+
2019-03-19 Akim Demaille <address@hidden>
bitset: fix memory leaks
diff --git a/lib/textstyle.in.h b/lib/textstyle.in.h
index 65fa6707a..3eb71938f 100644
--- a/lib/textstyle.in.h
+++ b/lib/textstyle.in.h
@@ -319,7 +319,8 @@ term_styled_ostream_create (int fd, const char *filename,
typedef styled_ostream_t html_styled_ostream_t;
static inline html_styled_ostream_t
-html_styled_ostream_create (ostream_t destination, const char *css_filename)
+html_styled_ostream_create (ostream_t destination _GL_UNUSED,
+ const char *css_filename _GL_UNUSED)
{
abort ();
return NULL;
>> which requires style_file_name to really exist, the #define won't do.
>> Maybe a set_style_file_name would be better?
>
> Such code is necessarily application-dependent. I think, a
> '#if HAVE_LIBTEXTSTYLE' around the entire block is the best approach
> here.
Ok, it makes sense.
>> BTW: did you really want the user to specify the .css part? In the
>> command line I prefer --style=foo to --style=foo.css, but we should
>> definitely have a single convention (which could be to support both:
>> add .css if the name has no extension).
>
> The documentation contains a section
> The end user's perspective > The --style option > Creating your own style
> files
>
> The very idea of the library is that the user can customize it.
Yes, I certainly do not want to hide this. I see your point but still would
not have made that decision; but the current behavior was made on purpose, it
has a rationale, so I'll be happy to live with that.
Cheers!