From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) by sourceware.org (Postfix) with ESMTPS id 242863858C39 for ; Wed, 6 Oct 2021 19:36:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 242863858C39 Received: by mail-qv1-xf32.google.com with SMTP id a14so2661584qvb.6 for ; Wed, 06 Oct 2021 12:36:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7Bobrj8o/+phvtIASoIVLRJt0mDqgHV8j2dZHi9Gl9c=; b=VDmM2oAwtVtgGcr+PP6itMYjseNtwhBaemT3TNTiO5H70FmouHMTmGVgz58haL+wV3 SKRPw/x1e0dObC9MF2w/PZZLqqDfiosP/WipbaUOchpte2x/Ox52xS5e3ZFmOHAfh4AM IiParu9Sx0bpeQp9QK+Xjs7WgQgJwtEAGAeJ/Whtq/2Zh0Fsu93f1Vc64keEFA5dveQB wGE4V8OfMmLGh9ihaoDXJOI7MSx+QCzDs9GUb/Yl7yZsYbg24Um4b5xMboEDwLP0YHaO 0CCfpgoc7w/bo3EXXWaW8t9JDlQvI9LQlURe/3UKtc7GQSAgVZH3RVKpUoHIzxcu1s7l IPsw== X-Gm-Message-State: AOAM532n2IHvNNcHQrnnm5TTtgkLa0mT6oyL+0wnRyKd86UuNAaXJQRW pT4CB2bUbZXdI/7Wb7qkYTYtNvUHQ5V+aA== X-Google-Smtp-Source: ABdhPJyF0/zSmbBjOXQkIZ5INJk65qZu73E9qzVYLN0XUCsPAnudkhlM7woKzgnajg51EszgW0D7ig== X-Received: by 2002:a0c:e409:: with SMTP id o9mr165641qvl.53.1633548970579; Wed, 06 Oct 2021 12:36:10 -0700 (PDT) Received: from ?IPv6:2804:431:c7cb:807a:2ebe:4b13:27bd:f11d? ([2804:431:c7cb:807a:2ebe:4b13:27bd:f11d]) by smtp.gmail.com with ESMTPSA id l20sm15159156qtk.19.2021.10.06.12.36.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 12:36:10 -0700 (PDT) Subject: Re: [PATCH 7/7] misc: syslog: Use RFC5424 To: Paul Eggert Cc: libc-alpha@sourceware.org References: <20211005135631.3209020-1-adhemerval.zanella@linaro.org> <20211005135631.3209020-8-adhemerval.zanella@linaro.org> <3e3847f2-b149-8202-1e45-b1e64074b54b@cs.ucla.edu> From: Adhemerval Zanella Message-ID: <0cbfa4bb-a5b5-9fa8-39e9-cadd3ba92330@linaro.org> Date: Wed, 6 Oct 2021 16:36:08 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <3e3847f2-b149-8202-1e45-b1e64074b54b@cs.ucla.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 19:36:12 -0000 On 05/10/2021 16:07, Paul Eggert wrote: > On 10/5/21 6:56 AM, Adhemerval Zanella via Libc-alpha wrote: > >> +struct timebuf_t >> +{ >> +  char b[sizeof ("YYYY-MM-DDThh:mm:ss.nnnnnnZ")]; >> +}; > > This won't work if people fiddle with their system clocks and set the time far in the future or past. I suggest including and using the following instead: > >   struct timebuf >   { >     /* Leave room for outlandish but possible years. >        The "+ 1" is for strftime's adding 1900 to tm_year.  */ >     char b[INT_STRLEN_BOUND (int) + 1 >        + sizeof "-MM-DDThh:mm:ss.nnnnnnZ"]; >   }; Indeed, I did not consider it and the suggestion makes sense. > > >> +  struct tm now_tm; >> +  __gmtime64_r (&ts.tv_sec, &now_tm); > > This messes up if __gmtime64_r fails, which is possible when time_t is very large (or very negative). > >> +  __snprintf (timebuf->b, sizeof (timebuf->b), >> +              "%04d-%02d-%02dT%02d:%02d:%02d.%06dZ", >> +              now_tm.tm_year + 1900, now_tm.tm_mon + 1, now_tm.tm_mday, >> +              now_tm.tm_hour, now_tm.tm_min, now_tm.tm_sec, >> +              (int32_t) ts.tv_nsec / 1000); > > This messes up if now_tm.tm_year + 1900 overflows. (strftime has a similar bug; it should get fixed too but one thing at a time.) Also, that 'int32_t' should be plain 'int', to match the format. And it's a bit better to not use casts when it's easy, as is the case here. > > I suggest something like this instead (I haven't tested it): > >   struct tm *gmtm = __gmtime64_r (&ts.tv_sec, &now_tm); >   if (gmtm == NULL) >     strcpy (timebuf->b, "-"); >   else >     { >       size_t datebytes = __strftime_l (timebuf->b, sizeof timebuf->b, >                                        "%FT%T", gmtm, _nl_C_locobj_ptr); >       int usec = ts.tv_nsec / 1000; >       __snprintf (timebuf->b + datebytes, sizeof timebuf->b - datebytes, >                   ".%06dZ", usec); >     } > > The "-" is as per RFC 5434's NILVALUE. It make sense, I changes to your suggestion thanks.