zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: type-checking for metafiedness? (was: Re: Cores almost on demand in patcompile())
Date: Sat, 15 Oct 2016 08:30:40 +0000	[thread overview]
Message-ID: <20161015083040.GA4462@fujitsu.shahaf.local2> (raw)
In-Reply-To: <37947.1476486298@hydra.kiddle.eu>

Oliver Kiddle wrote on Sat, Oct 15, 2016 at 01:04:58 +0200:
> Daniel Shahaf wrote:
> > > > This probably is a good idea, although the intermediate state where this
> > > > has been only partly done is likely to be a bit of a mess.
> 
> Starting out with a simple typedef would at least add documentation and
> allow an incremental approach. Would still need to add .v everywhere en
> masse when going to a struct, though.

Does anyone have a way to get type checking that doesn't involve
adding .v everywhere?  The solution doesn't _have_ to be portable; we
can use compiler-specific magic of gcc or clang, for example, so long as
some developers use that compiler routinely.

If we do the typedefs first, then adding .v later should be easy with
something like coccinelle's patching tool.  (It allows doing
search/replace in terms of the C syntax tree.)

> I did some work on a code base that had a convention of uint8_t*
> for UTF-8. Seemed to work well as far as I could tell.
> 

What's the advantage over chars or unsigned chars?

> For the history file we should perhaps consider not using locale
> dependent metafied strings. UTF-8 with an overlong encoding for a null
> perhaps? grep etc might still not like the overlong null but they should
> be rarer.

+1 to making the history file locale-agnostic.

> > allocated relative to each other, e.g., if the code assumes that
> > «ary[1] - ary[0] == 1+strlen(ary[0])» or otherwise uses the values of
> 
> Even with char**, that condition is only likely if the array was
> created with a literal assignment. And it is easy to test for
> problems by forcing the size of the struct and running the test
> cases.

I was thinking of code that allocates multiple elements in a single
malloc() chunk:

    char **array, *storage;
    for (i = 0; i < LENGTH_OF_LIST; i++)
        sum_of_lengths += strlen(list[i]) + 1;
    storage = malloc(sum_of_lengths);
    for (i = 0; i < LENGTH_OF_LIST; i++) {
        array[i] = strcpy(storage, list[i]);
        storage += strlen(array[i]) + 1;
    }

> Oliver
> 


  reply	other threads:[~2016-10-15  8:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-09  9:00 Cores almost on demand in patcompile() Sebastian Gniazdowski
2016-10-09  9:16 ` Sebastian Gniazdowski
2016-10-09 10:15   ` Sebastian Gniazdowski
2016-10-09 16:09     ` Sebastian Gniazdowski
2016-10-10 15:31       ` Sebastian Gniazdowski
2016-10-11  2:46         ` Bart Schaefer
2016-10-11  2:53           ` Bart Schaefer
2016-10-11  6:51           ` type-checking for metafiedness? (was: Re: Cores almost on demand in patcompile()) Daniel Shahaf
2016-10-13 10:22             ` Peter Stephenson
2016-10-13 13:46               ` Bart Schaefer
2016-10-14  6:36                 ` Daniel Shahaf
2016-10-14 16:53                   ` Peter Stephenson
2016-10-14 17:28                     ` Bart Schaefer
2016-10-14 20:08                     ` Daniel Shahaf
2016-10-14 23:04                   ` Oliver Kiddle
2016-10-15  8:30                     ` Daniel Shahaf [this message]
     [not found]                       ` <CAH+w=7bONQfKge=kWwFasKNXSu7510d8c+1aoYEeyUbozf_P7A@mail.gmail.com>
2016-10-15 18:35                         ` Fwd: " Bart Schaefer
2016-10-13  9:43           ` Cores almost on demand in patcompile() Peter Stephenson
2016-10-19 11:14             ` Sebastian Gniazdowski
2016-10-19 13:14               ` Peter Stephenson
     [not found]                 ` <CAKc7PVBhHFUWbMobAeDptgXmZ=S6RVsuNB7Qwsq555Srya_5qg@mail.gmail.com>
2016-10-20  8:56                   ` Bart Schaefer
2016-10-20  9:32                   ` Peter Stephenson
2016-10-20  9:56                     ` Sebastian Gniazdowski
2016-10-20 10:18                       ` Peter Stephenson
2016-10-20 10:30                         ` Sebastian Gniazdowski
2016-10-20 10:42                           ` Peter Stephenson
2016-10-20 10:56                             ` Peter Stephenson
2016-10-20 11:03                               ` Peter Stephenson
2016-10-20 11:09                                 ` Sebastian Gniazdowski
2016-10-20 11:23                                   ` Peter Stephenson
     [not found] <CGME20161016014741eucas1p189be6c2fa19aaf9d31733cae5f716178@eucas1p1.samsung.com>
2016-10-16  1:14 ` type-checking for metafiedness? (was: Re: Cores almost on demand in patcompile()) Bart Schaefer
2016-10-16 17:03   ` Daniel Shahaf
2016-10-18 11:36   ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161015083040.GA4462@fujitsu.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).