From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 09DFE42129 for ; Sat, 15 Jan 2022 18:33:52 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 109A568A6F6; Sat, 15 Jan 2022 20:33:50 +0200 (EET) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05olkn2091.outbound.protection.outlook.com [40.92.90.91]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E3F186807C5 for ; Sat, 15 Jan 2022 20:33:42 +0200 (EET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f86ton7nMPcM+ZP1uL81O8wrukAbvCndWR8COCMcPbaEerpSXFVygmsiBOuyfSalihZfUCaAIZoKhIsE5qBNahfr91ehISYYjLbDhIzI4A36EIitbxZGlcbl6SNRrzwvzxOhhod7DBw/Qlays4NPktJ26obtXuZ3FVBR6FZrXODuW9IlJn/pi3SIkKsoKWEtQBo30FXu5VGdlPVKmJZsSlWgCjipTPnGrwyeqyqO+8Mq5Pux8TPUDQhEIvoGAd0aKir9Rk/y/tOX9aU4IFVskPyOxcjZcr4ZP3PT/Y5oL0bZpwx5OFiVEVTy9t9BDHok9Hij3A99N5xq/SDTkGT87g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bvYO7i46kIA8V+x54e+hq/uoiTRT/TdMXFZDRfZsad8=; b=jhLjteJU7dJm4Wgw648NGczaMGniIxLi3nU3VMgI/3Dz/PPOOvFN5pW23SZr/enRUQ1B+LO7C8F7+71JaAV6ARVA/Ko8LyzxCfeYlSDCP6BGhkDn5jTaRUO77GcgqX/I8wplMN0hvJIEu7Gi2iOiQyauFUcNjEkwjsxJ9M5VqbaVsC3UALRuQjdzhOxhWMqDNrwAftGjMiHDgCzBKysH7Ts/b5L2vuFxC3LzdoxOJaJx3MnmCP5ZcpuqZRaWLqgJ67e3yMmfnuGqD2bAxrgoBLWa4w4yr8OvUnNuK25eQQS18zHAenpne4IgHaEazQN9t6ACfpX7nyZaEq4BNClbzw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bvYO7i46kIA8V+x54e+hq/uoiTRT/TdMXFZDRfZsad8=; b=UJEqGcODZFoeK6blNuxtFipvPIBSWPYoQPq9nn9uy+jvBuylydkW1QZ9bxQVXFawIXeQX2KggHNO09EWNVwW8ptOehF29wreJ1km58vyjULYXZGVy6lyyqBGBku8GtHF/sSk8noEFvSW+bFKVh6vcqkAoePY5uq4gASCx7eAU0WJZwobiwV0Mb+pMGpRbA5FCFzClYEdl2XS5geQVNrEdxD67JevKXdHoelvMnLkH8qA1nvyNVqAbfChQYapSQXDl9V/h9Dh9fOVN5JbVJQRgwnCKom78FF7SZiYhleRy5/arTGHRwsRM6i5iMPuD1czgXzmGDKLbOKGeUOHVAEHyg== Received: from AM7PR03MB6660.eurprd03.prod.outlook.com (2603:10a6:20b:1c1::22) by DB6PR03MB2854.eurprd03.prod.outlook.com (2603:10a6:6:34::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.11; Sat, 15 Jan 2022 18:33:40 +0000 Received: from AM7PR03MB6660.eurprd03.prod.outlook.com ([fe80::19fc:be9f:2c9c:53f5]) by AM7PR03MB6660.eurprd03.prod.outlook.com ([fe80::19fc:be9f:2c9c:53f5%9]) with mapi id 15.20.4888.013; Sat, 15 Jan 2022 18:33:40 +0000 Message-ID: Date: Sat, 15 Jan 2022 19:33:38 +0100 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: From: Andreas Rheinhardt In-Reply-To: X-TMN: [pZG2GESMF4a2exmfCRhNDHrIONfQcZmY] X-ClientProxiedBy: AS9PR06CA0061.eurprd06.prod.outlook.com (2603:10a6:20b:464::35) To AM7PR03MB6660.eurprd03.prod.outlook.com (2603:10a6:20b:1c1::22) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b9405ae0-0fd8-4e84-bb2e-08d9d8558cca X-MS-TrafficTypeDiagnostic: DB6PR03MB2854:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Lnt6xUFJC2WW+ZIEwbZFlV/OpRXnY8uRHf4ItIs3Eeeah0Vm5UIvwTFx4OaQLIn91hOnejXv2xwIK+a7Waf7Nv7+gl7efqw1bEustkSHs5hzwNZ9UZP4mE3edG2ISidg4x3LVUxcs1BYnlK1xkGd5l/xl00obmaV+hYMfS9pF8gBs1MNfw6Bs1ZxCoCcx0tVov6YUom/tJpBp/Wa+mwzxjntnFe6zVYssFgQF5Rau5m/BPIWzW8mXgO5CH7KOwaaD9zb4PqU78VDlseQI+XJFi3yIsECylhpySnVtMXfLbYZrHD8ZM3g5moSbJLpTy/IhrDElUCIwbeIIczUbsE2+sivSTaXlmXSTk8CI+pWPEr3VMUGrI8UIHrw08Ff9j7+Mf3/w+nx7vSYbsWR+SpjfiJxrkRJF6xNBr3yZ5vwPoxlJQm7ku8kRRbVBEklRvl+3FLg/4uMIaQ0xwTyhzR/QEvBtVA/pu/Qamdy9VOCunp9tdNksVe6VbM0JH+M8+qbzf7x2UY2BCUhSgydBWNTO0FNdvn4NSlWIfiXtDkS45B9mA5McwXQ2RS3ok+wZx6dkpY//qPztQxRViqlZmvWgAfPiZ9SwVjyx5m7gBGXOpkNmK63C6iOoGcIwABi82D9zu2MJsARV/VLU6qzqoFsMVF6FHIjN4aO4yiES/+t7DA= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZW9oV3ZjVGJhY1F0aGpBbTEzYXZoNVA2UEViQXVLaEg5WUpiZ3NjbGVXOEJi?= =?utf-8?B?WjdyTjdLU2xSQnlPUnh6eUEyaEhVTWxFS0MyMXFwTVJpQ3czT0IrUEttcTBw?= =?utf-8?B?ZEp4QUtRcWZIdmJEekNlVTlHSkhIZ3c1Q2JuWmdDUkR4UGpSMGEzazNMZ3FK?= =?utf-8?B?YStyL3BIMjNQWUFsazcrb1RzcUFVemJlQ3o2bzEvWVVqYWNKcmdCVS92OU5V?= =?utf-8?B?Y3loU2RBOUlzYVUzRFRTa3p3VzNRclRUMUpFTytxWnZkSzB3SE9xRGk3NFNa?= =?utf-8?B?TXZHbU1BcHlTQzZ6VFBKOHBHcU9XdmlvSVMxTnloRzVwUC9JZFFFK1NnclYx?= =?utf-8?B?Z1NnbEpEajE3SGd4dHljSmM4bHd1N1pDV1RKazltU1ZZSzRVdk9oaXFMb0Vs?= =?utf-8?B?UkFScFZaczhtRzhJTkZzZkYyd2pJemNhMXB4d01lak5DUWlybVR5MVpMazRp?= =?utf-8?B?T1VyT1lULy9UMGNVU2pOQjI2REpRZnlRL2VtbHozVWR6SzVWNU93dnd3K1Q5?= =?utf-8?B?ZXlsa3pvd1RFVkZjbWdDZTdLN2VsRVpDaEFJTHkrT3hHcERLTE5ORkxuV1ly?= =?utf-8?B?cEwvaitOWFlSYzNRT1duZHl6RmtvN3VxbFk4bFMvU2xKd2VjTE52R1doUUgy?= =?utf-8?B?ekMrZjZvSHJXUWRRUSt0alRFaG9paTMvNVNOc0phZDZIVzdYY0EreFhoZEU0?= =?utf-8?B?ME9xL3ZIRWJHVW1OU1FDanlWekJwNjJFOEd5c0Zrb3Q2UTBoVUFWMXdadFZC?= =?utf-8?B?ZzdRN3E0UEp4am5yQ3VWRVl6UEgwYXl5YTlMSVplaVd6R2dVTUxzaWpHVGpw?= =?utf-8?B?emgxT3dyLzROeFJGYU1SbnhXLzBzR2tBL0xQaUpuZXJsdjlmT09nay9SQytp?= =?utf-8?B?d1p0SmtUV0E1UHdEeUNEcHRhRUpWbGNLalc0Z2J4T2N5S2lrcFN4ZjRMYi8w?= =?utf-8?B?T1VBWXNHTG5pazhIZlVwMUhKRVo4b2tja1BwcmVQOEpBTDc0RzlVTC9zdkh3?= =?utf-8?B?VnF1M090Y3RZb0RiWmxMWWZ4bkduVWNqR1lIZVUzeGp6eHl5S0xkcFBoaWsy?= =?utf-8?B?VkZSazhFWTJLd3cxeFRSZFdjVWxGZEpZc0ovd1UwVVlpNWcrWlZjeGEzZmhF?= =?utf-8?B?Q2c3MXdtYlg3UnpWZWtpUmdpSFp0MEo5ZXg1SnVLTkcvV3MyRVhoNzkrbGJG?= =?utf-8?B?QUx5Q2lIRG1PbHZPTEZIR2NFOEhwT2hSNXBVN0x0cUZUMkh3R1p1amp6dVBO?= =?utf-8?B?MU9LYTUxVmE1UWEyYzMrdi84bmVTMWltZEw1ZjdUWEVXSm5Gdz09?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9405ae0-0fd8-4e84-bb2e-08d9d8558cca X-MS-Exchange-CrossTenant-AuthSource: AM7PR03MB6660.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2022 18:33:40.1191 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR03MB2854 Subject: Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Fix path handling on Windows X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Soft Works: > > >> -----Original Message----- >> From: ffmpeg-devel On Behalf Of Andreas >> Rheinhardt >> Sent: Saturday, January 15, 2022 7:40 AM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Fix path handling on >> Windows >> >> ffmpegagent: >>> From: softworkz >>> >>> Signed-off-by: softworkz >>> --- >>> avformat/hlsenc: Fix path handling on Windows >>> >>> Handling for DOS path separators was missing >>> >>> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr- >> ffstaging-19%2Fsoftworkz%2Fsubmit_hlspath-v1 >>> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging- >> 19/softworkz/submit_hlspath-v1 >>> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/19 >>> >>> libavformat/hlsenc.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c >>> index ef8973cea1..eff7f4212e 100644 >>> --- a/libavformat/hlsenc.c >>> +++ b/libavformat/hlsenc.c >>> @@ -3028,6 +3028,10 @@ static int hls_init(AVFormatContext *s) >>> } >>> >>> p = strrchr(vs->m3u8_name, '/'); >>> +#if HAVE_DOS_PATHS >>> + p = FFMAX(p, strrchr(vs->m3u8_name, '\\')); >>> +#endif >>> + >>> if (p) { >>> char tmp = *(++p); >>> *p = '\0'; >>> >>> base-commit: c936c319bd54f097cc1d75b1ee1c407d53215d71 >>> >> > > Thanks for reviewing. > >> 1. You seem to be under the impression that NULL <= all other pointers. >> This is wrong. Relational operators acting on pointers are only defined >> when both point to the same object (the case of "one past the last >> element of an array" is also allowed) and are undefined behaviour otherwise. > > The case about NULL is interesting - I wasn't aware of that. > Is it practically relevant, i.e. is there any platform where casting > (void *)0 does not evaluate to 0 ? > "An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant." (C11, 6.3.2.3 3) (void*)0 is therefore a valid null pointer constant and is also commonly used for the NULL macro. (void*)0 == 0 is always true, because the right hand side is converted to the type of the pointer (namely to a null pointer) and all null pointers compare equal. But this is irrelevant to relational comparisons, because checking for equality of pointers is not subject to these pointers pointing to the same object (or one past the last element of an array...), whereas this is so for relational operations. (If one uses unsigned for pointers, then one only needs to reserve two values that can not be used as part of an object: 0 and the max value (the latter can't be used for an object, because using a pointer one past the object is legal and has to be consistent with "<=" (and anyway said pointer must compare unequal to NULL)); if one used signed comparisons for pointers, one would have to reserve -1, 0 and the max value, the former because a one past the end array element needs to compare unequal to NULL and the latter to be consistent with <= and a potential one-past-the-end element. But this is a very small advantage. Honestly, I don't know whether compilers consistently use unsigned comparisons for pointer comparisons at all (even when restricted to compilers for systems with HAVE_DOS_PATHS). The fact that comparisons of pointers to different objects is UB means that compiler writers actually can choose what they want.) (Furthermore, it is not guaranteed by the spec that zeroing a pointer via memset (or calloc) generates a valid null pointer. E.g. the documentation of calloc has this footnote: "Note that this [the bitwise zero-initialization] need not be the same as the representation of floating-point zero or a null pointer constant." But I don't know a system where this is not so and we definitely require it to be so.) >> 2. Apart from that: Your code would potentially evaluate strrchr() >> multiple times which is bad style (given that this function is likely >> marked as pure the compiler could probably optimize the second call >> away, but this is not a given). > > It's not my code. It's code copied from avstring.c - so please blame > whoever that wrote. > I couldn't find strrchr() being evaluated multiple times unnecessarily due to a macro in avstring.c. > Regarding performance, I'm not sure whether this is relevant in any way, > given the low frequency of execution and putting it into relation to > all the other things that ffmpeg is doing usually. > The above would be a valid point if there were a tradeoff between writing the code without repeated evaluations and writing clear code. (And even then you'd be ignoring that the performance difference might be negligible for code only run very infrequently, but bloated code takes more space in the binary even when executed infrequently.) But there is no such tradeoff here. >> 3. The code in av_basename() is also wrong. > > ... > >> 4. Is there actually a reason why you don't use av_basename() directly here? > > Yes, multiple: > > 1. Different behavior - those functions are returning a "." when not found av_basename() also has precise guarantees when this happens. > 2. The docs tell it's required to copy a string before supplying it to > those functions (as they may changing the string). You are confusing av_basename() and av_dirname(). > 3. The hlsenc code changes the string temporarily and restores it after > wards. The same couldn't be done when using the avstring functions. > Why? In case you already know that the result is not a pointer to the static ".", you either get your path back (equivalent to no match) or a pointer to the char that you want to temporarily zero. (Granted, it is dubious whether using it is actually advantageous.) (Actually, your code is still slightly different from av_basename(): The latter has special handling for the drive separator ':' and I wanted to know why you don't. Given that this m3u8 path should always have a non-empty basename component, so there should not be a scenario where ':' is the FFMAX3.) - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".