Re: [dev] Coding style: why /* */ and not //?
On Thu, Jan 10, 2019 at 08:11:57PM +, sylvain.bertr...@gmail.com wrote: > Expect POSIX to add significant technical cost over time, like ISO, ANSI, > the most monstruous being the w3c. You ever try to write POSIX utilities according to the standard? Believe me, POSIX of all standards doesn't need to add anything to incur significant technical cost. Just say "cat -u". I mean, -v is considered harmful, but what about -u? Considered useless? system() is supposed to return 127 if the command interpreter could not be launched. That's mighty specific. cp -i is a thing. Etc. pp. However, for ISO C it is actually pretty easy to spot MS contributions. In this case, look at Annex K. C89 contained a lot of badly designed interfaces in Clause 7, so C95 added a few better designed alternatives (or bodges on the original design, depending on your view). And then M$ came along and added Annex K, where they added _s to a lot of functions and said "Use these henceforth. Just go through your code with a find-and-replace and then sin no more." And nobody, absolutely nobody bought it. These functions are also badly designed, but for other reasons than the C89 functions. Thankfully that whole nonsense is confined to an optional annex of the standard, that next to nobody implements. M$ does of course, but Visual Studio is not really relevant when it comes to C implementations. They still only implement C95, with cherry-picked features from C99, mostly ones that are also in C++. Ciao, Markus
Re: [dev] quark can not send files with '+' in the name
On Thu, 10 Jan 2019 23:27:12 +0300
Platon Ryzhikov wrote:
Dear Platon,
> I tried to use quark as local server for pacman but it returns 404
> error for files with '+' in filename. I found the following lines in
> http.c (83-85):
>
> if (*s == '+') {
> dest[i] = ' ';
> }
>
> Why does it replace '+' sign with space?
nice find! The snippet from http.c you are pointing to is part of the
decode() function. It is called during the parsing of the HTTP header
and used to decode URL-encoded strings.
URL-encoding is when you replace reserved characters (as specified in
Subsection 2.2 of RFC 3986[0]) with percent encoding. Space then turns
into %20, + turns into %2B and so forth. The list of reserved
characters is
: / ? # [ ] @ ! $ & ' ( ) * + , ; =
and it's the client's task to properly percent encode such characters
if necessary.
Now with URLs it gets a bit more complicated, as it's so-called
"application/x-www-form-urlencoded" content. Here it is actually, as
far as I understand, allowed by the client to replace spaces with + and
as a "reserved" character, which is not percent-encoded, the server
knows it means space. If you want to transmit a literal '+', you need to
percent encode it as %2B. Still, other servers behave differently and
keep the +, and spaces are properly percent encoded as %20 by the
clients I've tested.
Thus, I have removed the plus-replacement[1], because it serves no
purpose from what I can tell and there's no mention of it in the
standards. Effectively, this also resolves your problem as well.
Thanks for reaching out and using quark! :)
With best regards
Laslo Hunhold
[0]:https://tools.ietf.org/html/rfc3986
[1]:https://git.suckless.org/quark/commit/e299e186edba03192fc12f6709df48d02aa83849.html
--
Laslo Hunhold
pgp_HvBiyxJ3Q.pgp
Description: PGP signature
Re: [dev] Coding style: why /* */ and not //?
On Wed, 26 Dec 2018 at 03:56, Martin Tournoij wrote: > Don't want to start a discussion about it, but I'm curious why // is > disallowed? AFAIK all compilers accept // these days, and have for a > long time? Consistency, -- we only want one way of comments in code, as with everything else. Following the one way approach, leads to better consistency and less complexity. Besides this, /**/ is the more traditional style. The longer something is in place, the likelier it will be existent even longer ;) Thanks, Anselm
[dev] quark can not send files with '+' in the name
Hi
I tried to use quark as local server for pacman but it returns 404 error for
files with '+' in filename. I found the following lines in http.c (83-85):
if (*s == '+') {
dest[i] = ' ';
}
Why does it replace '+' sign with space?
Re: [dev] Coding style: why /* */ and not //?
A big warning: a "standard" is not anymore sufficient. Look at the microsoft xml document format at ISO. It means the corporations which have an interest at making file formats complex in order to kill any light software implementation alternative _will go through standard bodies_. Look at what did microsoft with pdf 2.0 at ISO too. Expect POSIX to add significant technical cost over time, like ISO, ANSI, the most monstruous being the w3c. -- Sylvain
Re: [dev] Coding style: why /* */ and not //?
Hello Martin, > The coding style says: > > > Use /* */ for comments, not // > > Don't want to start a discussion about it, but I'm curious why // is > disallowed? AFAIK all compilers accept // these days, and have for a > long time? > > I've always preferred // since they can nest (you can comment out a > function with //-style comments, but not with /* */-style comments), but > maybe I'm missing a downside of //-style comments? I guess you're talking about suckless coding style guide. Coding style guide is for published code. For your temporary testing code, you're free to comment lines with // if you want to, this will bother nobody else. We're talking about published code, so most of the arguments in favor of using // (like nesting comments) don't apply. Using /* */ is about commenting, not commenting out, and is more visible.
Re: [dev] Coding style: why /* */ and not //?
> > The only issue I see with c99 code is that some of the compilers > > appear to be behind the times on c. Any reason why we wouldn???t want > > to use a newer c feature other than compatibility? > > it's always about weighing convenience against freedom. Modern language > standards have picked up pace, comparable to web standards. By > voluntarily staying with a relatively simple, older version (like C99) > you don't "invest" into a new language that might turn out to be a > tough dependency in the long run. Do we really want to solely depend on > GCC And LLVM/Clang by using C11? C11 is not POSIX. Posix only recognice the tool c99. Older versions of the standard, c89. If you use cc, gcc ot c89 in current POSIX systems your code is not portable. If you don't agree, you can send a request to the POSIX commitee. Until that point, you will continue using c99 and following the POSIX standard. Best regards,
Re: [dev] Request version bump for 9base
Hi Stephen, On Wed, 9 Jan 2019 at 01:14, Stephen Gregoratto wrote: > I am interested in creating an OpenBSD port of 9base, as the current p9p > port depends on ghostscript (which I don't need on a server). However, > the current tagged version of 9base is now 8.5 years old, and there have > been many commits added since. > > Would it be possible for 9base to be "officially" bumped to version 7? We need to sync 9base against p9p tip first, then we can bump. We should have bumped like 3 years ago when there was the last effort on syncing with p9p. I hope to do that during the next days and then we can release 9base-7. I like that idea, since I'm still running a bunch of rc monitoring scripts besides werc, that work fine with "just" 9base. BR, Anselm
Re: [dev] Coding style: why /* */ and not //?
On Thu, 10 Jan 2019 08:46:51 -0500 stephen Turner wrote: Dear Stephen, > The only issue I see with c99 code is that some of the compilers > appear to be behind the times on c. Any reason why we wouldn’t want > to use a newer c feature other than compatibility? it's always about weighing convenience against freedom. Modern language standards have picked up pace, comparable to web standards. By voluntarily staying with a relatively simple, older version (like C99) you don't "invest" into a new language that might turn out to be a tough dependency in the long run. Do we really want to solely depend on GCC And LLVM/Clang by using C11? Using C99, it's possible to use independent compilers (e.g. scc), because it doesn't take 5000 man hours to implement it. But language choice is only one aspect, the other being avoiding GNU extensions. Does this have tradeoffs? Of course! But it often makes you rethink your algorithms and approaches, and come up with more elegant solutions. With best regards Laslo -- Laslo Hunhold pgp1j4G6YrIh3.pgp Description: PGP signature
Re: [dev] Coding style: why /* */ and not //?
The only issue I see with c99 code is that some of the compilers appear to be behind the times on c. Any reason why we wouldn’t want to use a newer c feature other than compatibility? Thanks, Stephen On Jan 10, 2019, at 4:27 AM, David Demelier wrote: Le 27/12/2018 à 11:10, Silvan Jegen a écrit : > The only downside of //-style comments that I can > see is that they are only allowed since C99[0]. Yes, but C99 was released 20 years ago. Perhaps it's okay to use it nowadays :) Regards, -- David
Re: [dev] Coding style: why /* */ and not //?
Le 27/12/2018 à 11:10, Silvan Jegen a écrit : The only downside of //-style comments that I can see is that they are only allowed since C99[0]. Yes, but C99 was released 20 years ago. Perhaps it's okay to use it nowadays :) Regards, -- David
Re: [dev] [dwm] Crash with emojis on title bar
On Thu, Jan 10, 2019 at 04:36:25AM +, Jakub Labath wrote:
> Hi
>
> So I experienced this problems myself , this was roughly my journey.
>
> I messed with fonts on my gentoo installing some from google some time
> after X would start crashing when surfing web.
> Eventually got lucky and found this website
> https://github.com/dylanaraps/neofetch that reproduces the crash
> reliably.
> (Culprit is the https://www.compart.com/en/unicode/U+1F5BC)
>
> Eventually traced the crash to
>
>
> dwm: fatal error: request code=138, error code=16
> X Error of failed request: BadLength (poly request too large or
> internal Xlib length error)
> Major opcode of failed request: 138 (RENDER)
> Minor opcode of failed request: 20 (RenderAddGlyphs)
> Serial number of failed request: 1858
> Current serial number in output stream: 1869
> xinit: connection to X server lost
>
> which brought me here.
>
> I tried the patch from Igor but while it prevented the crash it left
> my dwm unusable.
> Wrote my own hack that removes non-ascii characters from the text
> written on the title bar (or any dwm text) and I am happy since.
>
> I am attaching my hack for reference but I do not think it's patch
> worthy as it removes the ability to have any national characters.
>
> Maybe I am an edge case but I was shocked to see dwm crashing given
> that it was otherwise rock solid for a decade+.
> I understand that the problem may lie with Xft and maybe that is what
> needs to be fixed, but it still kind of makes dwm look bad.
>
> I mean failure to render a glyph should never take down the Xorg - can
> anyone think of a more intelligent way to defend against this?
>
> My OS is gentoo - latest dwm and my Xorg and Xft are the latest in gentoo
>
> x11-libs/libXft 2.3.2-r1
> x11-base/xorg-server 1.20.3
> media-fonts/noto 20170403 (google fonts)
>
> Cheers
>
> Jakub
> diff --git a/dwm.c b/dwm.c
> index 4465af1..dd9bbe2 100644
> --- a/dwm.c
> +++ b/dwm.c
> @@ -899,23 +899,40 @@ getstate(Window w)
> return result;
> }
>
> +void
> +sub_non_ascii_chars(char *txt, unsigned int size) {
> + int i;
> + for (i = 0; i < size; i++){
> +//fprintf(stderr, "%c at idx %d is %d\n", txt[i], i, txt[i]);
> +if (txt[i] > 127 || txt[i] < 0) {
> + txt[i] = '?';
> +}
> + }
> + //fprintf(stderr, "OUT |%s|\n", txt);
> +}
> +
> int
> gettextprop(Window w, Atom atom, char *text, unsigned int size)
> {
> char **list = NULL;
> int n;
> XTextProperty name;
> + char buf[size-1];
>
> if (!text || size == 0)
> return 0;
> text[0] = '\0';
> if (!XGetTextProperty(dpy, w, , atom) || !name.nitems)
> return 0;
> - if (name.encoding == XA_STRING)
> - strncpy(text, (char *)name.value, size - 1);
> - else {
> + if (name.encoding == XA_STRING) {
> + strncpy(buf, (char *)name.value, size - 1);
> + sub_non_ascii_chars(buf, size-1);
> + strncpy(text, buf, size - 1);
> + } else {
> if (XmbTextPropertyToTextList(dpy, , , ) >= Success
> && n > 0 && *list) {
> - strncpy(text, *list, size - 1);
> + strncpy(buf, *list, size - 1);
> + sub_non_ascii_chars(buf, size -1);
> + strncpy(text, buf, size - 1);
> XFreeStringList(list);
> }
> }
>
Hi Jakub,
It is a known issue (Google Noto fonts with color emojis) crashing Xft
applications. Not only dwm is affected.
The previous proposed fixes in this thread ignore the underlying errors, which
is bad. I like your workaround more, but it is still not a solution.
Xft needs to fix this known bug and/or we need to switch from Xft. The only
one looking bad is Xft here (and having color emojis in fonts).
--
Kind regards,
Hiltjo
